From FORRERJ@frl.orst.edu Tue Dec 06 11:59:53 1994
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rF4B4-0000kcC; Tue, 6 Dec 94 11:59 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id CAA02629 for <HFSIG@tapr.org>; Tue, 6 Dec 1994 02:38:14 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Tue, 6 Dec 94 9:59:02 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 6 Dec 94 9:58:39 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Tue, 6 Dec 1994 09:58:39 PST8PDT
Subject:       HF Channel simulator
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <A01D8F158A9@frl.orst.edu>

Hi all,

I have received some extra copies of the CCIR report 549-2 
"HF IONOSPERIC CHANNEL SIMULATORS" from Barry. Anyone still in need for a 
copy please e-mail me. Thanks Barry!

The simulator is coming along quite nicely - I have part implemented on the 
sound card DSP and the rest on the 486. The "flat fading" model 
is working in a fashion - the main problem presently is to make the 486 keep 
up with the sound card. I found that I had to implement quite a bit of the 
simulation work using table lookup methods instead of calls to the 486's FPU 
trancendental functions - just too slow. I'll share with you soon as that I 
have something that works reasonably well.


73's

--Johan, KC7WW

From k5yfw@sacdm10.kelly.af.mil  Tue Dec 06 12:45:03 1994
Return-Path: <k5yfw@sacdm10.kelly.af.mil>
Received: from sacdm10.kelly.af.mil by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rF4sf-0001fXC; Tue, 6 Dec 94 12:44 CST
Received:  by sacdm10.kelly.af.mil (5.65b/1.0.2-rct)
	id AA29948; Tue, 6 Dec 94 12:41:38 -0600
Message-Id: <9412061841.AA29948@sacdm10.kelly.af.mil>
Date: Tue, 6 Dec 94 12:41:37 -0600
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW)
Subject: Re: [HFSIG:116] HF Channel simulator
To: hfsig@tapr.org
X-Orig-Date: Tue, 6 Dec 94 12:04 CST
X-Orig-From: "Johan Forrer FL" <FORRERJ@frl.orst.edu>
X-Orig-Message-Id: <A01D8F158A9@frl.orst.edu>

In your message of  6 Dec 1994 at 1204 CST, you write:
> Hi all,
>
> I have received some extra copies of the CCIR report 549-2
> "HF IONOSPERIC CHANNEL SIMULATORS" from Barry. Anyone still in need for a
> copy please e-mail me. Thanks Barry!
>
> The simulator is coming along quite nicely - I have part implemented on the
> sound card DSP and the rest on the 486. The "flat fading" model
> is working in a fashion - the main problem presently is to make the 486 keep
> up with the sound card. I found that I had to implement quite a bit of the
> simulation work using table lookup methods instead of calls to the 486's FPU
> trancendental functions - just too slow. I'll share with you soon as that I
> have something that works reasonably well.
>
>
> 73's
>
> --Johan, KC7WW
>

I too received a copy of the CCIR...thanks a whole bunch Barry.  Now I
will have to read it and try to understand it.  Where's my old K&E
slipstick?

I too can make copies of the CCIR and will be happy to mail them...
just E-Mail me at k5yfw@sat.ampr.org.

FOR BARRY, I'd be very interested in getting the rest of REPORT 111,
INFLUENCE ON LONG-DISTANCE HF COMMUNICATIONS...that starts on the
last page of the CCIR you sent.  I'll send postage.

In other news, General xxxx (he doesn't want to be identified) of the
Army, Army/MARS program wants *all* MARS traffic to start going by
high speed data...HF/VHF/UHF, etc.  I think he's sold on PACTOR.  Ok
guys#...time to shine and I *KNOW* you can do it.

Keep those E-Mail messages flowing...this is the most interesting
mailgroup I subscribe to...and probably the most important.

I'm anxiously awaiting for my copy of the CD "Seek You".  See the
review in the Jan '95 QST.

73,

Walt (dba k5yfw)

# gender neutral from the NY "youse guys".
From FORRERJ@frl.orst.edu Mon Dec 12 10:56:19 1994
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rHE2r-0000BbC; Mon, 12 Dec 94 10:56 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id BAA02031 for <HFSIG@tapr.org>; Mon, 12 Dec 1994 01:35:19 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Mon, 12 Dec 94 8:54:50 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 12 Dec 94 8:54:28 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Mon, 12 Dec 1994 08:54:21 PST8PDT
Subject:       HF Channel simulator
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <A90CB2538A1@frl.orst.edu>

Greetings,

I am looking for volunteers to help validate the results of my HF channel 
simulator program. This is the version written in C. I am most 
interested in validating the statistics of the various fading paths - 
this needs to be obtained by several lengthy simulation runs. You would 
need to include your own statistic collection code, however, I will be 
happy to assist with this.

As a minimum to participate, you would need a reasonably fast computer
(something in the 486/33 class), a C compiler, and spread sheet/statistics 
analysis software. You would need to be able to read C code and be able to 
make a few code changes. I dont think this is rocket science - most of the 
background have been discussed on this SIG.

If you are seriously interested, please e-mail - it is a short program so 
it can be e-mailed directly. 

Any help in this regard would be greatly appreciated.


Thanks in advance and 73's 

Johan, KC7WW

From FORRERJ@frl.orst.edu Wed Dec 14 16:19:56 1994
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rI237-00015iC; Wed, 14 Dec 94 16:19 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id GAA14356 for <HFSIG@tapr.org>; Wed, 14 Dec 1994 06:58:43 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Wed, 14 Dec 94 14:18:24 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 14 Dec 94 14:18:15 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Wed, 14 Dec 1994 14:18:11 PST8PDT
Subject:       HF modulation schemes
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <AC632344275@frl.orst.edu>

Hi all,

Just thought that I would pass on word of a gem of a book that I have
been studing over the past few days:

"Principles and Practice of Multi-frequency telegraphy" by J.D Ralphs.
Peter Peregrinus (1985).

I saw it on a post to "rec.radio.amateur.digital.misc" and checked it 
out from our library. If it was not so expensive ($107), I would have 
considered buying a copy for my own reference.

This book is about "Piccolo", i.e. MFSK and covers some great
topics. It has, for instance the clearest non-math approach to explaining
matched filters that I have seen. It also goes into great lengths of
describing HF channel simulation and is a very useful extension of 
the materials on HF channel simulation previously posted on this SIG. Also
includes a chapter on how it rates against other modulation schemes, i.e. 
the 16-parallel DPSK MIL-188 modem (actually does somewhat better). 

Food for thought.

73's

Johan, KC7WW 
From karn@qualcomm.com Fri Dec 16 00:56:19 1994
Return-Path: <karn@qualcomm.com>
Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rIWaO-0001P8C; Fri, 16 Dec 94 00:56 CST
Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.4) id WAA00937; Thu, 15 Dec 1994 22:58:01 -0800
Date: Thu, 15 Dec 1994 22:58:01 -0800
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199412160658.WAA00937@servo.qualcomm.com>
To: hfsig@tapr.org
Subject: December QEX on Clover tests

The current issue of QEX has a rather interesting article on the
results of some tests on Clover II using an HF channel simulator.

The character error rate vs Eb/N0 curves (no ARQ) are very
telling. They compare several Clover data rates against a NATO HF
modem standard, STANAG 4285. What's particularly interesting is that
in both fading situations (1 and 2-path Rayleigh) STANAG 4285
outperformed CloverII by 10 dB or more for the same data rate (300
bps).

The author attributes much of the difference to STANAG 4285's use of a
3 Khz channel vs Clover's use of a 500 Hz channel. I think this
illustrates very nicely the perils of narrowband thinking. Consider
that STANAG 4285 not only requires less than 1/10 of the total
transmitter power of Clover II for the same data rate, but it spreads
it out over 6 times the bandwidth. This reduces the signal spectral
density by more than 60x or 16 dB. That's a significant reduction in
interference potential to others reusing the channel elsewhere.

The article also mentions MIL-STD-110A, saying that it's very similar
to (but incompatible with) STANAG 4285. Since we have a CD-ROM
database of MIL-STDs at work, I was able to print off a copy (81
pages). If someone is really interested in a copy, I could be
persuaded to make some more and mail them out.

Phil

From frode@dxcern.cern.ch  Fri Dec 16 02:42:32 1994
Return-Path: <frode@dxcern.cern.ch>
Received: from dxmint.cern.ch by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rIYFB-0000alC; Fri, 16 Dec 94 02:42 CST
Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26274; Fri, 16 Dec 1994 09:42:19 +0100
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19133; Fri, 16 Dec 1994 09:42:18 +0100
From: frode@dxcern.cern.ch (Frode Weierud)
Message-Id: <9412160842.AA19133@dxcern.cern.ch>
Subject: Re: [HFSIG:120] December QEX on Clover tests
To: hfsig@tapr.org
Date: Fri, 16 Dec 1994 09:42:17 +0100 (MET)
In-Reply-To: <199412160658.WAA00937@servo.qualcomm.com> from "Phil Karn" at Dec 16, 94 01:00:00 am
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1414      


Hi Phil,

The current issue of QEX has not yet arrived over here so
I have not seen this article, but I am looking forward
to study it.

Concerning STANAG 4285 and other NATO standards I have tried
several times to get access to them, but so far without any
success. Most of them are classified, some even quite heavily,
and I have not even got a reply to some of my requests.

When I get the QEX article I will again try to approach the
NATO standardisation people and see if I can get them to
cooperate.

I would like very much to have a copy of MIL-STD-188/110A,
"INTEROPERABILITY & PERFORMANCE STANDARDS FOR DATA MODEMS", so
if you can mail me a copy I will be extremely grateful.

I will cover you costs for postage etc. Please let me know
how I can reimburse you, with IRCs or a green bill in a letter.
I would like to avoid sending you a cheque as I have to pay
10.- SFr for each cheque and that is hardly worth it for small
amounts.

As Christmas is looming on the horizon I will take this
opportunity to wish you a Merry Christmas and a Happy New Year.

73 Frode, LA2RL


**************************************************************************
*	Frode Weierud		Phone	:	41 22 7674794		 *
*	CERN, SL		Fax	:	41 22 7679185		 *
*	CH-1211 Geneva 	23	E-mail	:	frode@dxcern.cern.ch	 *
*	Switzerland			   or	weierud@cernvm.cern.ch	 *
**************************************************************************

From muphaus@cris.com  Fri Dec 16 04:19:44 1994
Return-Path: <Muphaus@cris.com>
Received: from cris.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rIZlG-0001A9C; Fri, 16 Dec 94 04:19 CST
Received: from voyager.cris.com by cris.com [1-800-745-CRIS (voice)]
Received: by voyager.cris.com (4.1/SMI-4.1)
	id AA03227; Fri, 16 Dec 94 05:19:00 EST
To: hfsig@tapr.org
Cc: karn@qualcomm.com
From: muphaus@cris.com (Marv Uphaus)
Subject: Re: [HFSIG:120] December QEX on Clover tests
Date: Fri, 16 Dec 1994 03:01:47 -0600
Organization: Not Organized
Reply-To: muphaus@cris.com
Message-Id: <xTLykCysSUt8075yn@cris.com>
In-Reply-To: <199412160658.WAA00937@servo.qualcomm.com>
Lines: 22

On Fri, 16 Dec 94 01:00 CST, Phil Karn <karn@qualcomm.com> wrote:

>                                        Since we have a CD-ROM
>database of MIL-STDs at work, I was able to print off a copy (81
>pages). If someone is really interested in a copy, I could be
>persuaded to make some more and mail them out.
                                 ^^^^
Phil...

Shame on you...!!!  This is electronic media...  Find an FTP site to post
it on and just make an electronic copy of the 81 pages and let whoever
wants a copy FTP it and print it out themselves...  Since it's already
on CD-ROM that ought to take you about 1 minute to perform...

BTW, Johan, the HFSIG needs an ftp site to post information, results, etc.
that everyone can get to...  Any suggestions from anyone...

Marv...

--  Marv Uphaus  --  muphaus@cris.com  --  Ph: 205-343-9256  --
--  U.S.Mail: 4031 Airport Blvd. #49  --  Mobile, AL  36608  --
--  Packet Radio Address  --  K4BVG @W4IAX.#MOBAL.AL.USA.NA  --
From karn@qualcomm.com Fri Dec 16 04:34:28 1994
Return-Path: <karn@qualcomm.com>
Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rIZzW-00017RC; Fri, 16 Dec 94 04:34 CST
Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.4) id CAA03282; Fri, 16 Dec 1994 02:36:03 -0800
Date: Fri, 16 Dec 1994 02:36:03 -0800
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199412161036.CAA03282@servo.qualcomm.com>
To: muphaus@cris.com
CC: hfsig@tapr.org
In-reply-to: <xTLykCysSUt8075yn@cris.com> (muphaus@cris.com)
Subject: Re: [HFSIG:120] December QEX on Clover tests

>Shame on you...!!!  This is electronic media...  Find an FTP site to post
>it on and just make an electronic copy of the 81 pages and let whoever
>wants a copy FTP it and print it out themselves...  Since it's already
>on CD-ROM that ought to take you about 1 minute to perform...

The only problem is that the document is stored as an bitmap image on
the CD-ROM and the only useful thing to do with it is to print it on a
laser printer. I don't think the search software lets you do anything
else with it. Even if it did, the resulting files would be rather large.

Scanning it into ASCII is a possibility, but the image quality is
rather poor (much like a low res fax) and there are tables and diagrams...

Phil

From rs@ife.ee.ethz.ch Fri Dec 16 05:04:48 1994
Return-Path: <rs@ife.ee.ethz.ch>
Received: from bernina.ethz.ch by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rIaSr-00002mC; Fri, 16 Dec 94 05:04 CST
Received: from ife (actually ife-gw.ethz.ch) by bernina.ethz.ch 
          with SMTP inbound; Fri, 16 Dec 1994 12:04:22 +0100
From: Rolf Sommerhalder <rs@ife.ee.ethz.ch>
Message-Id: <9412161104.AA15107@ife>
Received: from ife.ee.ethz.ch (gillespie) by ife.ee.ethz.ch id AA15107;
          Fri, 16 Dec 1994 12:04:21 +0100
Received: by gillespie.ethz.ch; Fri, 16 Dec 94 12:04:21 +0100
Subject: Re: [HFSIG:123] Re: December QEX on Clover tests
To: hfsig@tapr.org
Date: Fri, 16 Dec 94 12:04:20 MET
In-Reply-To: <199412161036.CAA03282@servo.qualcomm.com>; from "Phil Karn" at Dec 16, 94 4:38 am
content-length: 858

> The only problem is that the document is stored as an bitmap image on
> the CD-ROM ...

Is that CD-ROM with Mil-Stds publically available ?  If so, do you know its source ?
(some Mil-Stds are available on the net, however, no the more recent/relevant
HF-modem standards).

73,
Rolf

-- 
                                --- * * * ---

Rolf Sommerhalder                             
Swiss Federal Institute of Technology (ETH)   home address:
Electronics Laboratory ETZ H60.1              c/o Rindlisbacher
Gloriastrasse 35                              Wermatswilerstrasse 96
8092 Zurich / Switzerland                     8610 Uster / Switzerland

Voice +41 1 632 76 40 (or 632 51 53)          Voice +41 1 941 59 28
Fax   +41 1 632 12 10                         AX.25 HB9CWP @ HB9OS
E-Mail rolf.sommerhalder@ife.ee.ethz.ch       Swiss Disaster Relief HBK81

From gjones@tenet.edu Fri Dec 16 06:56:12 1994
Return-Path: <gjones@tenet.edu>
Received: from Gayle-Gaston.tenet.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rIcCf-0000W1C; Fri, 16 Dec 94 06:56 CST
Received: (from gjones@localhost) by Gayle-Gaston.tenet.edu (8.6.9/8.6.9) id GAA02166 for hfsig@tapr.org; Fri, 16 Dec 1994 06:56:08 -0600
From: Greg Jones <gjones@tenet.edu>
Message-Id: <199412161256.GAA02166@Gayle-Gaston.tenet.edu>
Subject: Re: [HFSIG:122] Re: December QEX on Clover tests
To: hfsig@tapr.org
Date: Fri, 16 Dec 1994 06:56:07 -0600 (CST)
In-Reply-To: <xTLykCysSUt8075yn@cris.com> from "Marv Uphaus" at Dec 16, 94 04:21:00 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 1222      

Please feel free to use the tapr area on tcet.unt.edu
Hopefully we will be moving it over to tapr.org., but a few more things are
required before we do that.

Cheers - Greg

According to Marv Uphaus:
> 
> On Fri, 16 Dec 94 01:00 CST, Phil Karn <karn@qualcomm.com> wrote:
> 
> >                                        Since we have a CD-ROM
> >database of MIL-STDs at work, I was able to print off a copy (81
> >pages). If someone is really interested in a copy, I could be
> >persuaded to make some more and mail them out.
>                                  ^^^^
> Phil...
> 
> Shame on you...!!!  This is electronic media...  Find an FTP site to post
> it on and just make an electronic copy of the 81 pages and let whoever
> wants a copy FTP it and print it out themselves...  Since it's already
> on CD-ROM that ought to take you about 1 minute to perform...
> 
> BTW, Johan, the HFSIG needs an ftp site to post information, results, etc.
> that everyone can get to...  Any suggestions from anyone...
> 
> Marv...
> 
> --  Marv Uphaus  --  muphaus@cris.com  --  Ph: 205-343-9256  --
> --  U.S.Mail: 4031 Airport Blvd. #49  --  Mobile, AL  36608  --
> --  Packet Radio Address  --  K4BVG @W4IAX.#MOBAL.AL.USA.NA  --
> 

From frode@dxcern.cern.ch  Fri Dec 16 07:34:10 1994
Return-Path: <frode@dxcern.cern.ch>
Received: from dxmint.cern.ch by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rIcnN-00005hC; Fri, 16 Dec 94 07:34 CST
Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA20779; Fri, 16 Dec 1994 14:34:00 +0100
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24122; Fri, 16 Dec 1994 14:32:48 +0100
From: frode@dxcern.cern.ch (Frode Weierud)
Message-Id: <9412161332.AA24122@dxcern.cern.ch>
Subject: An introduction and an apology
To: hfsig@tapr.org
Date: Fri, 16 Dec 1994 14:32:47 +0100 (MET)
In-Reply-To: <9412161104.AA15107@ife> from "Rolf Sommerhalder" at Dec 16, 94 05:05:00 am
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2911      


Hi all,

As you have all seen that I exist, through my negligence
of not checking the address field before hitting the Return
key, I thought I at least could try to partly repair the
damage by offering you a short introduction of myself.

I have been following the discussions on the list for about
a month now and I have already learned a few things I did not
know. I have been interested in HF transmission modes for
more than 25 years and I have during those year been trying
to decode many, if not all, of the exotic modes you find on
the HF bands.

I am a licenced ham, LA2RL, but I have been living in the
Geneva, Switzerland area for the past 22 years and for
a large part of the time I have been unable to practice my hobby
due to lack of a reciprocal licence. This made me into a
"utility listener" which I still am, even if I rarely find
the time to devote to this activity.  Today I have a French
temporary licence, F/LA2RL, but unfortunately I rarely have
time for more than one QSO per week.  I still hope to be
able to find time to reactivate myself on the digital modes,
and to again have some contacts on RTTY and Amtor and to try
out the new Pactor mode. 

I have had the intention of informing you all about a few
papers that I have found of interest. Some of the references
I had in mind others have already found, so I will not repeat
those, but here are a few additional references:

You should try to have a closer look at a special issue of
IEEE Journal on Selected Areas in Communications, Vol. SAC-5,
No. 2, February 1987. This issue is dedicated to fading and
multipath channel communications.

Here are two of the papers that I have found interesting:

 - Seymour Stein; "Fading Channel Issues in System Engineering",
   pp.68-89.

 - Kenneth Brayer; "HF Data Transmission: Lessons from the Past,
   Directions for the Future", pp.90-101.

I have also seen reference to two reports on single tone modems that
it might be interesting to look at for those that would have
access to them. They are:

 - D.D. McRae, R.S. LeFever, and J.N. York; "HF modem feasibility
   demonstration", RADC-TR-2-48, Final Tech. Rep., Mar. 1981 -
   Oct. 1981.

 - P. Monsen and L.C. Perry; "HF modem test and evaluation",
   RADC-TR-3-19, Final Tech. Rep., Jan. 1983.

Over Christmas I plan to look through my old files and if I find
other papers of interest I will let you all know.

As I have already wished Phil a Merry Christmas and a Happy New
Year I now want to make amends by wish you all happy festivities
and a very fruitful and digital 1995.

73 Frode, LA2RL


**************************************************************************
*	Frode Weierud		Phone	:	41 22 7674794		 *
*	CERN, SL		Fax	:	41 22 7679185		 *
*	CH-1211 Geneva 	23	E-mail	:	frode@dxcern.cern.ch	 *
*	Switzerland			   or	weierud@cernvm.cern.ch	 *
**************************************************************************

From muphaus@cris.com  Sat Dec 17 11:51:18 1994
Return-Path: <Muphaus@cris.com>
Received: from cris.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rJ3Ho-0000aUC; Sat, 17 Dec 94 11:51 CST
Received: from voyager.cris.com by cris.com [1-800-745-CRIS (voice)]
Received: by voyager.cris.com (4.1/SMI-4.1)
	id AA17746; Sat, 17 Dec 94 12:50:37 EST
To: hfsig@tapr.org
From: muphaus@cris.com (Marv Uphaus)
Subject: Re: [HFSIG:123] Re: December QEX on Clover tests
Date: Fri, 16 Dec 1994 17:03:07 -0600
Organization: Not Organized
Reply-To: muphaus@cris.com
Message-Id: <hoXykCysSgWD075yn@cris.com>
In-Reply-To: <199412161036.CAA03282@servo.qualcomm.com>
Lines: 26

On Fri, 16 Dec 94 04:39 CST, Phil Karn <karn@qualcomm.com> wrote:

>The only problem is that the document is stored as an bitmap image on
>the CD-ROM and the only useful thing to do with it is to print it on a
>laser printer.

Phil...

Post the file as a "filename.ps" (post script file) to tcet.unt.edu...  
Then anyone with access to a postscript printer (most people have a friend 
with one) can print it out...  Another option would be to put the file on a 
WWW page in graphic form and then it can be looked at on-line...  (but 
pretty slow even at 14400...)  If you post it as a file somewhere, I will 
try some OCR software on it and see if we can convert it to ASCII and the 
diagrams to .BMP files...

There are a lot of options besides printing it out in hardcopy...  We
should NEVER have to do that again...  That was what the paper companies
were afraid of years ago at the beginning of the computer revolution...  So
far it hasn't happened but it's close at hand...!!!

73...  Marv...

--  Marv Uphaus  --  muphaus@cris.com  --  Ph: 205-343-9256  --
--  U.S.Mail: 4031 Airport Blvd. #49  --  Mobile, AL  36608  --
--  Packet Radio Address  --  K4BVG @W4IAX.#MOBAL.AL.USA.NA  --
From karn@unix.ka9q.ampr.org Sun Dec 18 02:10:31 1994
Return-Path: <karn@unix.ka9q.ampr.org>
Received: from unix.ka9q.ampr.org by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rJGhH-0000Z8C; Sun, 18 Dec 94 02:10 CST
Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.7/8.6.5) id AAA00477; Sun, 18 Dec 1994 00:10:35 -0800
Date: Sun, 18 Dec 1994 00:10:35 -0800
From: Phil Karn <karn@unix.ka9q.ampr.org>
Message-Id: <199412180810.AAA00477@unix.ka9q.ampr.org>
To: muphaus@cris.com (Marv Uphaus)
CC: hfsig@tapr.org
In-reply-to: <hoXykCysSgWD075yn@cris.com> (muphaus@cris.com)
Subject: Re: [HFSIG:127] Re: December QEX on Clover tests

The problem is that this is a proprietary packaged system, and there
doesn't seem to be any way to get the data out of it in electronic form.
I don't even know that it sends Postscript to the printer; it's an HP
LaserJet III, so it could well be talking PCL for all I know.

By the way, to whoever maintains this mailing list: items are coming
out with a "Reply-To:" header that points to the list. That makes it
difficult to reply privately to the sender of a message. This is not
good in my opinion.

Phil

From k5yfw@k5yfw.ampr.org  Sun Dec 18 09:23:17 1994
Return-Path: <k5yfw@k5yfw.ampr.org>
Received: from k5yfw.ampr.org by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rJNS3-0000MvC; Sun, 18 Dec 94 09:23 CST
Date: Sun, 18 Dec 94 08:17:44 CST
Message-Id: <2355@k5yfw.ampr.org>
From: k5yfw@k5yfw.ampr.org (Walter D. DuBose - K5YFW)
Reply-To: k5yfw@sat.n5lyt.ampr.org
To: hfsig@tapr.org, tcp-group@ucsd.edu, kd5i@kazak.nmsu.edu
Subject: Re: Achieving regulation by bandwidth
In-Reply-To: Your message of Fri, 16 Dec 1994 08:52:09 -0700 (MST)
X-Mailer: Bdale's Mailer version PA3AZK.940404 (MSDOS)

Seasons Greetings to you Karl and All.

In message <Pine.SUN.3.91.941216082204.24883C-100000@kazak> Karl writes:
> 
> 	It's a pet theory of mine. I believe that a standard "rice box" 
> HF rig such as my Kenwood TS-140 has decient filtering in the IF for a 
> voice. It seems to be matched very well to the 1200 baud FM modulated 
> waveform used for years on VHF. I have experimented with other pbbs 
> sysop's on 10 meters using 1200 baud. 

        That would seem constant with my use of 1200 baud on 10 meter FM
        several years ago.  But, I must comment that signals on the band
        very were stable.  I suspect that I was getting little/few
        multi-path signals to cause distortion.  However, at the first
        hint of signal degration, I would lose connectivity while the
        signal strength was still strong.  At that time, I didn't know
        Multi-path signal distortion.

> 
> 	The results were spectacular! We had such good radio paths that 
> we could use maxframes of 2 and 3! The data rate was comperable to that 
> acheived on vhf if the pbbs were in the same town talking direct to each 
> other. I didn't get a ticket from the FCC for using data on a voice only 
> frequency. I didn't get anything. When propagation got bad we quit.

        As referenced above, it is (now to me) a well know fact that
        there is rapid fading observed on HF circuits that is the result
        of interference between a number of different waves that have
        been refracted from different portions of the ionosphere.  Each
        refracted wave will arrive at the receive antenna as a slightly
        different time.  This frequency or phase shift will mask a
        received data signal that has a baud rate generally above 150
        baud.

        With little or no multi-path signal distortion, 300 baud, and
        above is possible.  However, in most cases you must be below
        150-200 baud to prevent this problem from causing detection
        problems.  In severe cases, the problem may exist down to 100
        baud.

        Since the above applies to AFSK and FSK, my assumption is that
        FM AFSK would also be affected.

        I was running 1200 baud below 28.3 KHz.

> 
> 	Reality says that 20 meters is where you need to be if you want 
> to pass traffic on HF during a sunspot minimum. It has been shown that 
> 300 baud packet radio is not as viable as Pactor and some other software 
> designed for the limited bandwidth we allow ourselves in the "CW" portion 
> of the band. I say if we go to 1200 baud in the "Phone" portion of the 
> band we will stir up some discussion and show that packet radio works 
> well on HF.

        Please reference my comments above on multi-path signal
        distortion.

> 
> 	I am willing to set up a 1200 baud packet forwarding frequency in 
> the Extra Class portion of the band, say 14.54 MHz, lower sideband. I 
> need at least another sysop willing to try this. The reason for doing 
> this is 2 fold. It will measure how well 1200 baud works on 20 meters and 
> provide some real data to show FCC at a future time when we want to argue 
> for regulation by bandwidth used, not type of modulation.  

        I believe that someone else has referenece the fact that data
        transmissions are only authorized, in areas under control of the
        F.C.C. between 14.00 MHz and 14.15 MHz on the 20 meter band.

        Additionally, F.C.C. rules, Part 97.305 Authorized emission
        types, (97.307 Emission standards) authorizes only a "symbolic
        rate must not exceed 300 bauds, or for frequency shift keying,
        the frequency shift between the mark and space must not exceed
        1 KHz."

        Operating 1200 baud in the U.S. Phone band on 20 meters, if
        under the jurisduction of the F.C.C. Rules Part 97 is
        prohibited.  However, the F.C.C. might allow experimenting if
        properly solicited.

> 
> 
> 	73, de karl k5di@k5di.nm.usa.na k5di@acca.nmsu.edu 
>            DOS and Windows some say are bad software, but facts
>            do not support this. Bill Gates has more than a 
> 			Billion dollars! 

There is a group who are interested in developing robust high speed
data transmission protocols for HF.  The thread(s) can be found by
subscribing to "hfsig@tapr.org".  For precise subscription directions,
try sending E-Mail to listserv@tapr.org and in the text send only the
work help...if this doesn't work, send the word info.  But I'm willing
to bet that someone like Greg Jones, will tell you just how to subscribe
(are you reading this Greg?).

My burning desire is to be able to run 2400 BPS on HF like the $7,500 to
$15,000 modems that the military use only using an off-the-shelf
computer sound card.  The military runs 2400 BPS on HF with better
thru-put than ten AMTOR stations at the same S:N ratio.  I also want to
be able to interface TCP/IP (SMTP) from V/UHF AmprNet LANS to an HF
AmprNet WAN.

73,

Walt@home.4.the.week-end


From karn@unix.ka9q.ampr.org Sun Dec 18 23:52:12 1994
Return-Path: <karn@unix.ka9q.ampr.org>
Received: from unix.ka9q.ampr.org by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rJb10-0000jFC; Sun, 18 Dec 94 23:52 CST
Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.7/8.6.5) id VAA01428; Sun, 18 Dec 1994 21:52:55 -0800
Date: Sun, 18 Dec 1994 21:52:55 -0800
From: Phil Karn <karn@unix.ka9q.ampr.org>
Message-Id: <199412190552.VAA01428@unix.ka9q.ampr.org>
To: rs@ife.ee.ethz.ch
CC: hfsig@tapr.org
In-reply-to: <9412161104.AA15107@ife> (message from Rolf Sommerhalder on Fri, 16 Dec 94 05:05 CST)
Subject: Re: [HFSIG:124] Re: December QEX on Clover tests

>Is that CD-ROM with Mil-Stds publically available ?  If so, do you know its source ?
>(some Mil-Stds are available on the net, however, no the more recent/relevant
>HF-modem standards).

My company subscribes to a commercial CD-ROM service for this stuff. I
don't know much about it except the name: "Information Handling
Services". Probably rather expensive, given the number of CD-ROMs.

Phil

From Rick_Whiting@ATK.COM Mon Dec 19 12:54:18 1994
Return-Path: <Rick_Whiting@ATK.COM>
Received: from ATK.COM by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rJnDn-0000w7C; Mon, 19 Dec 94 12:54 CST
Received: from gateway1 by ATK.COM (8.6.9/8.6.9)
	id MAA06689; Mon, 19 Dec 1994 12:53:05 -0600
Message-Id: <199412191853.MAA06689@ATK.COM>
Date: 19 Dec 1994 11:10:39 -0600
From: "Rick Whiting" <Rick_Whiting@ATK.COM>
Subject: FWD>RE>M4X- TMS320C4x Commu
To: "Post hfsig TAPR" <hfsig@tapr.org>
CC: Darrell_Sawyer@gateway1.ATK.COM

Mail*Link(r) SMTP               FWD>RE>M4X: TMS320C4x Communica

Date: 12/19/94 10:55 AM
From: Rick Whiting
In article <3cnkcp$pcu@tilde.csc.ti.com>
Keith Larson <xkel@msg.ti.com> writes:

>                 M4X EVALUATION SOFTWARE NOW AVAILABLE
> 
>        A Multiprocessing TMS320C4x Communications and Debug Kernel 
> 
> What is M4X and how do I get a copy
> -----------------------------------
>   M4X is a complete reference design for a multiprocessing system of
TMS320C4x
> devices.  All materials for M4X are contained in one self extracting file
> (M4X.EXE) which is available as freeware from the TMS320 BBS (713-274-2323)
> where the original source will be maintained.  Under a freeware agreement
you
> are allowed to use, modify and freely distribute (IE no charge) this code
so 
> long as you provide reference to the original authors.  
> 
>   NOTE: At this time the M4X reference design is intended for evaluation
use 
> only and will NOT be posted to TI's BBS ftp site until after the evaluation
> period is completed.
> 
> Who might be interested in M4X
> ------------------------------
>   This application is best suited for builders and hackers.  To use this
> application you will need to build your own interface card (less than $5 in
> parts) and target system (more than $5) from the descriptions given in the
M4X
> documentation.  M4X is intended for those individuals who are willing to
> participate in the development of an open, user supported standard.  If you
> make significant advancements, please contact the original M4X developers
to
> have your ideas incorporated.
> 
> Support
> -------
>    M4X will NOT be supported by the TMS320 Hotline.  Instead, users should
send
> messages, comments and code to other M4X users through the TMS3230 BBS, or
an
> internet group, when and if it should form.
> 
> What is contained in M4X.EXE
> ----------------------------
>   M4X.EXE is a self extracting executable which contains several
executables, 
> source files and documentation.  The main files, and what they do, are
given below.
>  
> M4X.ASM - Assembly source code for TMS3204x runtime kernel.  Provides
>          bi-directional split mode DMA and commport control for packetized 
>          routing of commands and data.
> 
> M4XD.EXE - Multiprocessing M4X debugger interface which runs in a 
>          standard DOS window.  Multiple DOS windows and debug nodes are 
>          allowed. Sorry no source code can be made available for this 
>          debugger!
> 
> MANDEL40.EXE - Very fast multiprocessor version of the Mandelbrot set.  
>          Runs a full screen SVGA capable of 640x480 256 colors
> 
> MEMVIEW.EXE - Multiprocessor memory viewer which runs independent of other
M4X 
>          tasks.  You can use this to asynchronously read and display data  
   
>          blocks in a running system.
> 
> Documentation - ICSPAT Conference paper (in postscript) and M4X
documentation  
>          are included.  The M4X kernel and applications were first
introduced  
>          and demonstrated at the DSP World, ICSPAT conference in Dallas in 
   
>          October 1994.
> 
> Theory of Operation
> -------------------
>   The M4x system utilizes the commport bootload feature of the TMS320C4x to

> initialize an unknown system of processors in a wavefront bootload process.

> The bootload process detects all valid connections, no connects and null
> outputs and builds an interconnection matrix from the bootup data.
> 
>   When loaded the M4X kernel provides several low level functions which 
> are used to manage a multiprocessor system.  The functions include getmem, 
> putmem, matrix management, call, branch, run, halt and singlestep. 
> 
>   The host communicates with the system through I/O driver and target 
> command processing code.  The I/O driver code interfaces with the hardware
to 
> provide token, data strobe and fifo control.  The target command software
is 
> then responsible for sending and receiving packetized command streams from 
> the system.
> 
>   The application code provided shows a user how to interface applications
to a
> system in a general purpose and easy to use manner.   Other important
system 
> level functions which are provided include the system bootloader, coff file
> loader, data transfer protocols, and simple run, stop and debug.
>   
>   Two I/O circuits are given which can be used to connect a TMS320C4x
commport
> to a PC's printer port (needs to be bi-directional).  These simple circuits
> are designed to provide the neccessary buffering and logic through software
> control to achieve a bi-directional general purpose link to a TMS320C4x
comport.
> Since all of the  printer port signals are uni-directional, simple
buffering
> techniques can be used to provide links of unlimited distance.  This
interface
> is also easily converted to other processors such as the TMS320C3x.
> 
> Conclusion 
> ----------
>   M4X has been developed to provide a starting point for the low level BIOS
> framework of a multiprocessing system.  When coupled with higher levels of 
> functionality there are many possabilities.  At this time it is definitely
NOT
> complete and still needs lots of work.  It just takes time and effort!
> 
> Best regards, 
> Keith Larson
> 
> Disclaimers
> -----------
>   They said it could'nt be done, so I did it!
> 
>   If you follow the rules that everybody else follows, you are
>   doomed to repeat the actions of everybody else!
> 
>   There is no such thing as a free lunch!
> 
>   I have been known to make a mistake or two, this is how I learn!
> 
>   If you see a bug.. Kill it first!  Then give me a call.
> 
>   Yes, I also created the C26 DSK...  and I am very busy.
> 


 ---------------------------------------------------------------------
| Rick Whiting                Office Phone 612-931-5344               |
| 5780 Rosewood Lane N.       Home Phone   612-550-1213               |
| Plymouth, MN 55442          Fax          612-931-5735               |
| U.S.A.                      E-mail       rick_whiting@atk.com       |
|                             Packet       W0TN @ WB0GDB.MN.USA.NOAM  |
 ---------------------------------------------------------------------



From Rick_Whiting@ATK.COM Mon Dec 19 13:47:53 1994
Return-Path: <Rick_Whiting@ATK.COM>
Received: from ATK.COM by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rJo1u-0000VEC; Mon, 19 Dec 94 13:45 CST
Received: from gateway1 by ATK.COM (8.6.9/8.6.9)
	id NAA07633; Mon, 19 Dec 1994 13:43:53 -0600
Message-Id: <199412191943.NAA07633@ATK.COM>
Date: 19 Dec 1994 11:08:41 -0600
From: "Rick Whiting" <Rick_Whiting@ATK.COM>
Subject: FWD>RE>New 56002 Evaluation
To: "Post hfsig TAPR" <hfsig@tapr.org>
CC: Darrell_Sawyer@gateway1.ATK.COM

Mail*Link(r) SMTP               FWD>RE>New 56002 Evaluation Mod

Date: 12/19/94 10:55 AM
From: Rick Whiting
In article <kirk.787276719@mustang18>
kirk@rtsg.mot.com (Michael J. Kirk) writes:

> Please excuse me if this info has 
> already been posted.  I just wanted to share
> this with anyone who might be interested in a low
> cost DSP evaluation tool.   I found it listed in the 
> October 1994 issue of DSP & Multimedia Technology.
> 
> WHO: Motorola Semiconductor Products Sector
>      Digital Signal Processor Division
>      (512)-891-3717
> 
> WHAT: A DSP56002 evaluation module containing:
>         Hardware:
>         Fully assembled and tested printed circuit board with
>           DSP56002, 24 bit fixed point DSP, 40MHz
>           32k X 24 external SRAM
>           Crystal Semiconductor MWAVE CS4215 Stereo Codec
>           MC7805ACT voltage regulator
>           MCHC705K1 microcontroller for RS232 to OnCE interface
>           MC33078 preamp for analog buffering
>           Jacks for stereo inputs, outputs and headphones
>           Documentation for DSP56002, CS4215, ASSEMBLER, and
>              DEBUGGER plus board schematics
>         Software:
>           Motorola's DSP5600x cross assembler for PCs
>           Domain Technologies debug software with (DOS?)
>            based windowed interface, SYMBOLIC DEBUGGING!
>           Installation instructions
>           Demo software and self test files
>         Requirements:
>           User must provide: 
>           Power supply (7-9V AC or DC) with spade terminals or
>                2.1 mm plug
>           RS-232 cable with DB-9 connectors    
>           IBM PC compatible (-386 class or higher) running
>            MS-DOS with 19200 baud serial port
>         Options:
>           32k X 8 EEPROM for bootstrapping and stand-alone operation
>           second RS-232 connector for access to DSP56002 SCI port
>           second crystal for other sample rates, e.g. 44.1kHz
> 
> HOW MUCH: US$ 149.95 + shipping and applicable taxes
>          Includes everything in WHAT above.
> 
> WHERE:  This offer may not be available outside the US
>         check with your local Motorola sales office.
> 
> WHEN: Available now.
> 
> WHY:  To get more people using Motorola DSP's
>       To offer an alternative to TI's US$99 evaluation kit
> 
> All for now...
> 
> Mike Kirk
> Senior Engineer
> Motorola, Inc.
> Cellular Infrastructure Group
> 1475 W. Shure Drive
> Arlington Heights, IL  60004
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| Rick Whiting                Office Phone 612-931-5344               |
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From karn@unix.ka9q.ampr.org Mon Dec 19 16:04:37 1994
Return-Path: <karn@unix.ka9q.ampr.org>
Received: from unix.ka9q.ampr.org by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rJqBx-0001BuC; Mon, 19 Dec 94 16:04 CST
Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.7/8.6.5) id OAA02330; Mon, 19 Dec 1994 14:03:50 -0800
Date: Mon, 19 Dec 1994 14:03:50 -0800
From: Phil Karn <karn@unix.ka9q.ampr.org>
Message-Id: <199412192203.OAA02330@unix.ka9q.ampr.org>
To: k5yfw@k5yfw.ampr.org
CC: hfsig@tapr.org
Reply-To: karn@qualcomm.com
In-reply-to: <2355@k5yfw.ampr.org>
Subject: Re: [HFSIG:129] Re: Achieving regulation by bandwidth

>        With little or no multi-path signal distortion, 300 baud, and
>        above is possible.  However, in most cases you must be below
>        150-200 baud to prevent this problem from causing detection
>        problems.  In severe cases, the problem may exist down to 100
>        baud.

So don't use a high baud rate. This implies multiple bits per
transmitted symbol (channel state change). This can be done either
orthogonally or non-orthogonally. Orthogonal simply means that all of
the possible channel states can be detected independently, without
mutual interference. Binary FSK with a sufficiently wide shift for the
baud rate is the classic example; you can build a "tone filter" that
responds just to mark, and another one that responds only to space.

But nothing limits FSK to just two tones. If you used, say 256
distinct tones then you could encode the 256 possible combinations of
an 8-bit data symbol as one of the 256 tones. This would be 256-ary
FSK.  The general scheme is called m-ary FSK and has long been known
to be one of the best schemes around for fading HF channels. The
higher the value of m, the better the performance -- assuming you can
spare the bandwidth.

The most common NON-orthogonal signalling scheme for multiple bits per
transmitted symbol is QAM. This maps a n-bit data symbol into 2^n
possible combinations of carrier amplitude and phase.  QAM's big
advantage is very good bandwidth efficiency for large values of n,
which is why it's universal in telephone line modems. But big values
of n mean very closely packed signal constellations, and relatively
little noise is required to move one received signal state to another
one nearby and cause an error. So the bandwidth efficiency of QAM
comes at the price of a much higher required S/N ratio. This is again
okay for telephone modems where the S/N ratio is usually 30 dB or
more, but (in my opinion) it is completely inappropriate for noisy,
interference-prone radio channels.

So once again we're back to the conclusion that to build a decent HF
modem that provides a good link with minimum transmitter power, we
really need to do something to relax the bandwidth limits.

Phil
From FORRERJ@frl.orst.edu Mon Dec 19 17:09:17 1994
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rJrCc-0001HTC; Mon, 19 Dec 94 17:09 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id HAA01298 for <hfsig@tapr.org>; Mon, 19 Dec 1994 07:47:51 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Mon, 19 Dec 94 15:07:40 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 19 Dec 94 15:07:09 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Mon, 19 Dec 1994 15:07:05 PST8PDT
Subject:       Re: [HFSIG:133] Re: Achieving regulation by bandwidth
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <B3F06525272@frl.orst.edu>

Phil Karn wrote:

>So don't use a high baud rate. This implies multiple bits per
>transmitted symbol (channel state change). This can be done either
>orthogonally or non-orthogonally. Orthogonal simply means that all of
>the possible channel states can be detected independently, without
>mutual interference. Binary FSK with a sufficiently wide shift for the
>baud rate is the classic example; you can build a "tone filter" that
>responds just to mark, and another one that responds only to space.

>But nothing limits FSK to just two tones. If you used, say 256
>distinct tones then you could encode the 256 possible combinations of
>an 8-bit data symbol as one of the 256 tones. This would be 256-ary
>FSK.  The general scheme is called m-ary FSK and has long been known
>to be one of the best schemes around for fading HF channels. The
>higher the value of m, the better the performance -- assuming you can
>spare the bandwidth.

As supporting arguments to above, please see J.D. Ralphs's book:
Principles and practice of multi-frequency telegraphy. Peter Peregrinus,
ISBN 0-86341-022-7. This book includes extensive chapters on
how such a system is engineered around the symbol set and signaling rate to 
combat the properties of the HF channel. It also compares this m-FSK to the 
MIL-STD-188A 16-tone parallel modems and comes out a nose ahead of the 
pack. The book also describes a simple synchronous detector that would 
be quite simple to implement on our present DSP platforms. If you are 
interested in using an HF channel simultor this reference also contains 
very useful stuff.


>The most common NON-orthogonal signalling scheme for multiple bits per
>transmitted symbol is QAM. This maps a n-bit data symbol into 2^n
>possible combinations of carrier amplitude and phase.  QAM's big
>advantage is very good bandwidth efficiency for large values of n,
>which is why it's universal in telephone line modems. But big values
>of n mean very closely packed signal constellations, and relatively
>little noise is required to move one received signal state to another
>one nearby and cause an error. So the bandwidth efficiency of QAM
>comes at the price of a much higher required S/N ratio. This is again
>okay for telephone modems where the S/N ratio is usually 30 dB or
>more, but (in my opinion) it is completely inappropriate for noisy,
>interference-prone radio channels.

The possibilities of QAM is quite attractive. Its signaling 
constallation is shown to have distinct robustness over other
alternative schemes of phase/amplitude signaling especially under 
conditions that include conditions of phase jitter (please see the Foschini 
paper that I posted a while ago). 

I have been thinking about the possibilities of QAM especially after 
reading Ralphs' book. He describes a simple procedure that is based on 
a simple synchronization sequence, and once lock is achieved, the PLL stays 
locked during the remainder of the frame (he gives supportive arguments of
its merits). If the signalling rate is chosen appropiately, the system will 
tolerate a considerable amount of phase distortion. I would like to invite 
further comments on this type of idea. I am not sure why, if this is such a 
scheme is this good, why have we not seen more general acceptance?



>So once again we're back to the conclusion that to build a decent HF
>modem that provides a good link with minimum transmitter power, we
>really need to do something to relax the bandwidth limits.
>Phil



Ditto - it is inevitable, however, even 1kHz would take us a long way and 
this is within part 97.

73's

Johan, KC7WW
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According to Phil Karn:
> So once again we're back to the conclusion that to build a decent HF
> modem that provides a good link with minimum transmitter power, we
> really need to do something to relax the bandwidth limits.

How wide are we talking Phil ?

Which bandwidth limits are you discussing?

Greg

From karn@unix.ka9q.ampr.org Mon Dec 19 20:05:44 1994
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CC: hfsig@tapr.org
In-reply-to: <B3F06525272@frl.orst.edu> (FORRERJ@frl.orst.edu)
Subject: Re: [HFSIG:134] Re: Achieving regulation by bandwidth
Reply-To: karn@qualcomm.com

>The possibilities of QAM is quite attractive. Its signaling 
>constallation is shown to have distinct robustness over other
>alternative schemes of phase/amplitude signaling especially under 
>conditions that include conditions of phase jitter (please see the Foschini 
>paper that I posted a while ago). 

I'm not convinced. QAM requires phase-coherent detection, but the HF
channel is inherently phase random. A Rayleigh fading channel model
has a Rayleigh probability distribution on amplitude (hence the name)
and a uniform distribution of phase between 0 and 2pi - i.e., the
received phase is completely random and can carry no information due
to the constantly changing and unpredictable propagation path lengths.
Although you might be able to get away with phase modulation on some
particularly benign HF channel, especially if there are only a small
number of path components, it sure doesn't seem like a wise thing to
rely on in your design.

So this implies noncoherent demodulation, i.e., just looking at signal
energy and ignoring phase. m-ary FSK can be demodulated this way. As
you increase m towards infinity you not only gain back everything you
lost by going noncoherent, but you also approach the -1.6dB Shannon
limit!

This stuff actually works. Although the details and implementation are
quite different, Qualcomm's CDMA system uses 64-ary modulation on the
reverse (mobile-to-cell) link in order to make up for the lack of a
coherent carrier phase reference over the Rayleigh-faded mobile radio
channel. The orthogonal codes are Walsh functions over time instead of
collections of sine waves over frequency, but the same principles
apply.

--Phil
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From: Phil Karn <karn@unix.ka9q.ampr.org>
Message-Id: <199412200227.SAA03205@unix.ka9q.ampr.org>
To: gjones@tenet.edu
CC: hfsig@tapr.org
In-reply-to: <199412192358.RAA13787@Gayle-Gaston.tenet.edu> (message from Greg Jones on Mon, 19 Dec 94 18:01 CST)
Subject: Re: [HFSIG:135] Re: Achieving regulation by bandwidth

>Which bandwidth limits are you discussing?

Those on the bottom half of each HF band. 

>How wide are we talking Phil ?

As wide as possible, as long as we stay in the band. For short-term
practical reasons, a good start would be 2-3 Khz. That fits in a SSB
filter so existing HF transceivers could be used without modification
by simply writing the appropriate DSP code to drive them with baseband
audio.

>Which bandwidth limits are you discussing?

Those on the bottom half of each HF band, where "data" is allowed.

Phil


From FORRERJ@frl.orst.edu Tue Dec 20 10:58:48 1994
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rK7td-0000X2C; Tue, 20 Dec 94 10:58 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id BAA03669 for <HFSIG@tapr.org>; Tue, 20 Dec 1994 01:37:51 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Tue, 20 Dec 94 8:57:41 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 20 Dec 94 8:57:33 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Tue, 20 Dec 1994 08:57:26 PST8PDT
Subject:       TAPR 1995 Annual meeting
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <B50DDD479AB@frl.orst.edu>

Hi all,

I hope that everyone is giving this meeting serious thought? 
If you are interested in DSP, and you should by now (?). This
will be a good place to be. This will be an excellent opportunity to
get first-hand impressions on what are being done and also an
opportunity to attend the seminars. I am looking forward to hearing
Phil's presentation on "Error correction coding". This is, in my 
opinion, a key component in a modern communication system. It's just a 
shame that the two planned seminars are in a time conflict as I would have
loved attending the DSP-93 seminar too. Is there any possibility
in re-arranging these venues?

I have also been approached to present a paper, and though, public speaking
is not my favorite passtime, I will consider a topic. I have sufficient
materials on two topics:

1) An implementation of PACTOR on a PC. This could look at the Pactor 
protocol, its good and not-so-good aspects, how frame sync is achieved and
maintained through brute-force algorithms, memory ARQ, and how this 
is integrated into the sound card's DSP.

2) The "HFSIG" HF channel simulator. This could include the Watterson model,
a summary of various bits and pieces as contributed on this SIG, and my 
simple PC/DSP-sound card implementation.


Suggestions?

73's, Johan KC7WW
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Phil Karn wrote:


>>The possibilities of QAM is quite attractive. Its signaling 
>>constallation is shown to have distinct robustness over other
>>alternative schemes of phase/amplitude signaling especially under 
>>conditions that include conditions of phase jitter (please see the 
>>Foschini >paper that I posted a while ago). 

>I'm not convinced. QAM requires phase-coherent detection, but the HF
>channel is inherently phase random. A Rayleigh fading channel model
>has a Rayleigh probability distribution on amplitude (hence the name)
>and a uniform distribution of phase between 0 and 2pi - i.e., the
>received phase is completely random and can carry no information due
>to the constantly changing and unpredictable propagation path lengths.
>Although you might be able to get away with phase modulation on some
>particularly benign HF channel, especially if there are only a small
>number of path components, it sure doesn't seem like a wise thing to
>rely on in your design.

>So this implies noncoherent demodulation, i.e., just looking at signal
>energy and ignoring phase. m-ary FSK can be demodulated this way. As
>you increase m towards infinity you not only gain back everything you
>lost by going noncoherent, but you also approach the -1.6dB Shannon
>limit!


Yes that is quite true if you consider doing things the way its done
on telco circuits, 

i.e. "matched filter" == coherent demodulation + integrate&dump + 
                          thresholding.

It would be really valuable getting hold of Ralph's book and see the 
logic of relaxing the coherent demodulation requirement. He calls it 
"quasi" 
coherent detection and still uses matched filters, though at passband, i.e. 
filters engineered and spaced as matched filters at passband instead of at 
baseband. I am sure that using this scheme I can implement DPSK + at least 
some form of amplitude modulation like being done on Clover. Although this 
is not quite the same as true QAM by definition, we can still 
achieve multiple bits per baud and also enjoy the bandwidth efficiency
benefits. Does this make any sense - is it worth looking into?

---further stuff deleted ---

I think we are making progress - keep up the good work.

73's, Johan, KC7WW
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According to Johan Forrer                                                                             FL:
> I hope that everyone is giving this meeting serious thought? 
> If you are interested in DSP, and you should by now (?). This
> will be a good place to be. This will be an excellent opportunity to
> get first-hand impressions on what are being done and also an
> opportunity to attend the seminars. I am looking forward to hearing
> Phil's presentation on "Error correction coding". This is, in my 
> opinion, a key component in a modern communication system. It's just a 
> shame that the two planned seminars are in a time conflict as I would have
> loved attending the DSP-93 seminar too. Is there any possibility
> in re-arranging these venues?

Hum -- interesting comment.  I'll talk to Phil, Bob, and Mel and see what we
might be able to do.  I should have realized this when Mel and myself sat
down and did the inital schedules.

The reason for finishing up around noon is to give folks a chance to fly out
the rest of the afternoon.  If a session is from 1pm till 4 or 5pm will
people stay and be able to get their flight out.  or maybe shoten PHil's a
tad and Bob's a tad, but people will still want to go to lunch sometime :-)
You can see the problems.

Greg
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Hi all,

Phil, it may help a great deal and be very beneficial to a lot of us if you 
could be so kind and, in a paragraph or so, explain what is meant by:

Channel capacity (entropy),

Spectral occupancy,

Bandwidth efficiency,

and how all this eventually relates to the Shannon limit.

I'm certain that understanding these definitions will help us understand 
better what we are trying to achieve. From your past postings, you have a 
great talent for making such stuff clear.

Thanks a lot in advance.

73's, Johan, KC7WW 
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Message-Id: <Pine.SUN.3.90.941220095521.28112U-100000@daffyduck>
Mime-Version: 1.0
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On Tue, 20 Dec 1994, Johan Forrer FL wrote:

> 
> I have also been approached to present a paper, and though, public speaking
> is not my favorite passtime, I will consider a topic. I have sufficient
> materials on two topics:
> 

> 
> Suggestions?
> 

How about a summary of the issues that have been debated on this net? For 
instance: 

* Is more bandwidth for digital HF channels necessary/desirable/feasible?
* What modulation techniques are presently under evaluation? What are the 
pros and cons of each.
* DSP platforms for HF signal processing: pros and cons of different 
makes, writing portable code.

All of this may be self-evident to those who have been following this 
group for a while, but to outsiders a summary could be instructive.

	Hugh
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On Tue, 20 Dec 1994, Hugh Shane wrote:

>> 
>> I have also been approached to present a paper, and though, public 
speaking
>> is not my favorite passtime, I will consider a topic. I have sufficient
>> materials on two topics:
>> 

>> 
>> Suggestions?
>> 

>How about a summary of the issues that have been debated on this net? For 
>instance: 

>* Is more bandwidth for digital HF channels necessary/desirable/feasible?
>* What modulation techniques are presently under evaluation? What are the 
>pros and cons of each.


I'm afraid that I have to pass this one to someone more capable as
I don't think that I can do justice that these deserve. How about you Hugh?


>* DSP platforms for HF signal processing: pros and cons of different 
>makes, writing portable code.
>All of this may be self-evident to those who have been following this 
>group for a while, but to outsiders a summary could be instructive.


I can consider this one, if it is not taken as a cheap shot at the
TAPR-93. How does others feel about it? Let us hear your suggestions.


73's

Johan, KC7WW
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I haven't posted to a list before, so let's see if this works...

In all the discussion about the best modulation format for HF, I'm
surprised nobody has mentioned OFDM.  Orthogonal frequency-division
multiplex is proposed for Digital Audio Broadcasting and digital TV
in Europe, although it is not so well known in the US.

The idea is to split the signal up into a large number (like 128 or
1024) equally-spaced carriers, each modulated at the same symbol rate.  
I believe the DAB standard proposes that each carrier be modulated 
with QPSK, but you can use any modulation in which each symbol can be 
represented by a phase and amplitude.  That includes the many forms of 
QAM, PSK, PI/4 DQPSK, on-off keying, whatever.

For example, If you use 128 carriers, the symbol rate is reduced by
a factor of 128, greatly reducing the probability of inter-symbol
interference due to multipath propagation.  Adding forward error
correction and time and frequency interleaving reduces the probability 
of bit errors due to selective fading on one or more carriers.

The reason the mode is called "orthogonal" FDM is that the carrier
frequency spacing is 1/symbol period, which theoretically eliminates
interference from all unwanted carriers.  This is easiest to see in 
the time domain.  For a symbol rate of 1 symbol/s, the carriers will
be spaced 1 Hz apart.  During each symbol period, the detector for
each carrier receives a certain number of RF cycles of the desired 
carrier.  During that same time period, each unwanted carrier has a 
number of cycles that differ from the desired carrier by an integer.
Convolving two sine waves that differ by an integer number of cycles 
gives zero result.

You could implement OFDM by building 128 RF oscillators, 128 I/Q
modulators, and the associated controlling hardware.  But there's a 
much simpler way, and here's the clever part of OFDM:

I mentioned that the signal consists of a series of equally-spaced
RF signals, each characterized by an amplitude and a phase.  If you
do an inverse DFT on that data, you come out with the time samples
of the composite signal!  At the kinds of data rates we are talking
about, an inexpensive DSP would be plenty fast enough.  For example, 
a 12.5 MHz ADSP21xx can do a 256-point DFT in 0.59 ms.  So we're
talking about a $10 DSP and a single I/Q modulator running at very
low symbol rates.  

For example, 128 QPSK carriers spaced 7.5 Hz apart (7.5 baud) gives
1920 bits per second within the 1 kHz bandwidth limit.  The DSP
has 1/7.5 = 133 ns to do all its calculations.

The choice of modulation type for the carriers affects only the
amplitude/phase list for each symbol.  So it would be easy to 
change modulation types to respond to different propagation
conditions, ala Clover.  By including the capability to do various
size FFTs, different symbol rates could be implemented using the
same bit rate within the same bandwidth.  i.e.  use very slow
symbol rates (large FFT) under fast Rayleigh fading conditions
and faster symbol rates (small FFT) with slow flat fading.

Alan Bloom N1AL
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Alan Bloom wrote:

>I haven't posted to a list before, so let's see if this works...

Welcome Al - glad you found us.

--some stuff deleted ---

>The idea is to split the signal up into a large number (like 128 or
>1024) equally-spaced carriers, each modulated at the same symbol rate.  
>I believe the DAB standard proposes that each carrier be modulated 
>with QPSK, but you can use any modulation in which each symbol can be 
>represented by a phase and amplitude.  That includes the many forms of 
>QAM, PSK, PI/4 DQPSK, on-off keying, whatever.

If I understand it correctly, I do believe that the 39-tone parallel 
MIL-STD-188 modem that have been mentioned on this group, is based on 
a similar principle - if I understand it correctly? 

-- more stuff deleted --

>I mentioned that the signal consists of a series of equally-spaced
>RF signals, each characterized by an amplitude and a phase.  If you
>do an inverse DFT on that data, you come out with the time samples
>of the composite signal!  At the kinds of data rates we are talking
>about, an inexpensive DSP would be plenty fast enough.  For example, 
>a 12.5 MHz ADSP21xx can do a 256-point DFT in 0.59 ms.  So we're
>talking about a $10 DSP and a single I/Q modulator running at very
>low symbol rates.  

>For example, 128 QPSK carriers spaced 7.5 Hz apart (7.5 baud) gives
>1920 bits per second within the 1 kHz bandwidth limit.  The DSP
>has 1/7.5 = 133 ns to do all its calculations.

>The choice of modulation type for the carriers affects only the
>amplitude/phase list for each symbol.  So it would be easy to 
>change modulation types to respond to different propagation
>conditions, ala Clover.  By including the capability to do various
>size FFTs, different symbol rates could be implemented using the
>same bit rate within the same bandwidth.  i.e.  use very slow
>symbol rates (large FFT) under fast Rayleigh fading conditions
>and faster symbol rates (small FFT) with slow flat fading.

This is interesting - one question: did we overcome the need for
coherent detection, or does it matter?

73's

Johan, KC7WW
From FORRERJ@frl.orst.edu Tue Dec 20 18:26:51 1994
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rKEtE-0000vTC; Tue, 20 Dec 94 18:26 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id JAA06450 for <hfsig@tapr.org>; Tue, 20 Dec 1994 09:05:54 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Tue, 20 Dec 94 16:25:44 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 20 Dec 94 16:25:39 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Tue, 20 Dec 1994 16:25:36 PST8PDT
Subject:       Re: [HFSIG:145] Re: HF Modulation Modes
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <B5855F80B9A@frl.orst.edu>

Some further food for thought:


Here are some further details on the 16-tone MIL-STD-188C modem
and a comparitive M-FSK system, just for interest sake. 

This MIL-STD modem uses 16 simultaneous tones, each modulated at 75 baud 
(13.3 ms elements) in two or four phases giving a maximal rate of 
2x75x16=2400 bit/s in 3 kHz. The tones are spaced at 110 Hz, orthoganal 
for the matched filter integration period of 9.1 ms, which allows for a 
guard time of +/- 2ms to cater for a limited degree of sych. error. 
The provision of guard periods causes an effective power loss of 
1.75 dB. Assuming each tone quadrature modulated, the normalized bandwidth 
is 3 Hz/bit/s.  However, extending this to 16 parallel tones, this yields 
0.87 Hz/bit/s, which is pretty close to the ultimate.

I have some further specifications on its BER, but unfortunately not
with me at the moment. Walt, K5YFW, could perhaps attest how these
have been doing on the military HF nets. This is living proof that
phase modulation is worth considering on HF.

One consideration when dealing with such a multi-tone signaling system, 
that the power rating of the transmitter is rated on the assumption that a
single unmodulated carrier is radiated, however, with multiple tones 
the output power is reduced by the square of the number of tones. Also
remember that, when dealing with the combination of such multiple tones
that a "noise-like" waveform results with possibly high peak/RMS ratio 
(i.e. crest factor) that may cause distortion or inter-modulation effects.  

According to Ralph's book, a 6-channel 6-FSK (i.e. six 6-FSK systems 
paralleled using similar bandwidth) outperforms this MIL-STD-188C 
modem. Sounds interesting?


73's

Johan, KC7WW
From bart@wb6hqk.ampr.org  Tue Dec 20 20:00:42 1994
Return-Path: <wb6hqk!bart@gatekeeper.ent-img.com>
Received: from gatekeeper.ent-img.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rKGM3-0000s6C; Tue, 20 Dec 94 20:00 CST
Received: from wb6hqk by gatekeeper.ent-img.com with uucp
	(Smail3.1.28.1 #5) id m0rKG8p-0004lHC; Tue, 20 Dec 94 17:46 PST
Received: by wb6hqk.ampr.org (Smail3.1.28.1 #2)
	id m0rKFSd-0004bNC; Tue, 20 Dec 94 17:03 WET
Message-Id: <m0rKFSd-0004bNC@wb6hqk.ampr.org>
From: bart@wb6hqk.ampr.org (Bart Rowlett)
Subject: please subscribe
To: hfsig@tapr.org
Date: Tue, 20 Dec 1994 17:03:23 -0800 (PST)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 11        

subscribe

From shall@rain.org Tue Dec 20 22:14:13 1994
Return-Path: <shall@rain.org>
Received: from coyote.rain.org by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rKIRG-00014HC; Tue, 20 Dec 94 22:14 CST
Received: by coyote.rain.org(4.1/SMI-RAIN) with id AA09238 
	  for hfsig@tapr.org on Tue, 20 Dec 94 20:10:26 PST
Date: Tue, 20 Dec 1994 20:10:25 -0800 (PST)
From: Stephen Hall <shall@rain.org>
To: hfsig@tapr.org
Cc: hfsig@tapr.org
Subject: Re: [HFSIG:136] Re: Achieving regulation by bandwidth
In-Reply-To: <199412200206.SAA03125@unix.ka9q.ampr.org>
Message-Id: <Pine.SUN.3.90.941220200614.7789C-100000@coyote.rain.org>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Greetings Phil, Steve here, WM6P.  Have not seen you since my visit to 
Qualcomm.  I recently left Harris Corp but may be able to get you in 
touch with some of the guys that developed the Harris serial and parallel 
tone HF modems.  They seem to know as much as anyone at this point that I 
have run into.

73, Steve
From BLOOM_ALAN/HP5300_R0@opnmail3.corp.hp.com Tue Dec 20 22:20:22 1994
Return-Path: <BLOOM_ALAN/HP5300_R0@opnmail3.corp.hp.com>
Received: from hp.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rKIXD-0000sCC; Tue, 20 Dec 94 22:20 CST
Received: from opnmail3.corp.hp.com by hp.com with SMTP
	(1.37.109.14/15.5+ECS 3.3) id AA146613616; Tue, 20 Dec 1994 20:20:16 -0800
Received: from  by opnmail3.corp.hp.com with SMTP
	(1.37.109.8/15.5+ECS 3.3) id AA24661; Tue, 20 Dec 1994 20:20:15 -0800
From: BLOOM_ALAN/HP5300_R0@opnmail3.corp.hp.com
X-Openmail-Hops: 2
Date: Tue, 20 Dec 94 20:20:00 -0800
Message-Id: <"d0eqoS-000000000*"@MHS>
In-Reply-To: <"B570F42212D(l)a(*"@MHS>
Subject: [HFSIG:145] Re: HF Modulation Modes
To: hfsig@tapr.org

Johan KC6WW said:

>This is interesting - one question: did we overcome the need for
>coherent detection, or does it matter?

On the receiving end, I presume you would just run a DFT on the
incoming sampled data which would output the frequency and phase
of each carrier.  It is effectively coherent detection, since
the phase is known.

Alan N1AL
From k5yfw@k5yfw.ampr.org  Tue Dec 20 23:59:07 1994
Return-Path: <k5yfw@k5yfw.ampr.org>
Received: from k5yfw.ampr.org by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rKK3o-0001KEC; Tue, 20 Dec 94 23:58 CST
Date: Tue, 20 Dec 94 23:18:59 CST
Message-Id: <2378@k5yfw.ampr.org>
From: k5yfw@k5yfw.ampr.org (Walter D. DuBose - K5YFW)
Reply-To: k5yfw@sat.n5lyt.ampr.org
To: hfsig@tapr.org
Subject: Re: [HFSIG:144] HF Modulation Modes
In-Reply-To: Your message of Tue, 20 Dec 94 16:18 CST
X-Mailer: Bdale's Mailer version PA3AZK.940404 (MSDOS)

Gee Alan, kinda sounds like the 16 & 39 parallel tone modem formats in
MIL-STD-188-110c.  16 or 39 parallel tones, with QPSK, inter-leaving and
Reed-Soloman coding for FEC.  In the 39 tone modem, a 40th tone has no
modulation and is called the Doppler Tone.  If phase shift is detected
on it, the modem knows than inter-symbol interference due to multipath
propagation is taking place.  The baud rate on the 39 tone modem is less
than 50 baud and the bandwidth of the signal is 3 KHz.  The transmitted
"data thruput rate (their terminology) is 2400 BPS.  The actual
transmitted bit rate is 3200-3600...I've forgotten and don't want to dig
into my files tonight.  The CLOVER II is a 4 parallel tone modem (and a
few other things) and runs 850-900 BPS.

Walt@home.2.nite

In message <9412202217.AA06592@eagle.sr.hp.com> you write:
> I haven't posted to a list before, so let's see if this works...
> 
> In all the discussion about the best modulation format for HF, I'm
> surprised nobody has mentioned OFDM.  Orthogonal frequency-division
> multiplex is proposed for Digital Audio Broadcasting and digital TV
> in Europe, although it is not so well known in the US.
> 
> The idea is to split the signal up into a large number (like 128 or
> 1024) equally-spaced carriers, each modulated at the same symbol rate.  
> I believe the DAB standard proposes that each carrier be modulated 
> with QPSK, but you can use any modulation in which each symbol can be 
> represented by a phase and amplitude.  That includes the many forms of 
> QAM, PSK, PI/4 DQPSK, on-off keying, whatever.
> 
> For example, If you use 128 carriers, the symbol rate is reduced by
> a factor of 128, greatly reducing the probability of inter-symbol
> interference due to multipath propagation.  Adding forward error
> correction and time and frequency interleaving reduces the probability 
> of bit errors due to selective fading on one or more carriers.
> 
> The reason the mode is called "orthogonal" FDM is that the carrier
> frequency spacing is 1/symbol period, which theoretically eliminates
> interference from all unwanted carriers.  This is easiest to see in 
> the time domain.  For a symbol rate of 1 symbol/s, the carriers will
> be spaced 1 Hz apart.  During each symbol period, the detector for
> each carrier receives a certain number of RF cycles of the desired 
> carrier.  During that same time period, each unwanted carrier has a 
> number of cycles that differ from the desired carrier by an integer.
> Convolving two sine waves that differ by an integer number of cycles 
> gives zero result.
> 
> You could implement OFDM by building 128 RF oscillators, 128 I/Q
> modulators, and the associated controlling hardware.  But there's a 
> much simpler way, and here's the clever part of OFDM:
> 
> I mentioned that the signal consists of a series of equally-spaced
> RF signals, each characterized by an amplitude and a phase.  If you
> do an inverse DFT on that data, you come out with the time samples
> of the composite signal!  At the kinds of data rates we are talking
> about, an inexpensive DSP would be plenty fast enough.  For example, 
> a 12.5 MHz ADSP21xx can do a 256-point DFT in 0.59 ms.  So we're
> talking about a $10 DSP and a single I/Q modulator running at very
> low symbol rates.  
> 
> For example, 128 QPSK carriers spaced 7.5 Hz apart (7.5 baud) gives
> 1920 bits per second within the 1 kHz bandwidth limit.  The DSP
> has 1/7.5 = 133 ns to do all its calculations.
> 
> The choice of modulation type for the carriers affects only the
> amplitude/phase list for each symbol.  So it would be easy to 
> change modulation types to respond to different propagation
> conditions, ala Clover.  By including the capability to do various
> size FFTs, different symbol rates could be implemented using the
> same bit rate within the same bandwidth.  i.e.  use very slow
> symbol rates (large FFT) under fast Rayleigh fading conditions
> and faster symbol rates (small FFT) with slow flat fading.
> 
> Alan Bloom N1AL
> 
> 
From k5yfw@k5yfw.ampr.org  Tue Dec 20 23:59:12 1994
Return-Path: <k5yfw@k5yfw.ampr.org>
Received: from k5yfw.ampr.org by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rKK3T-0000VAC; Tue, 20 Dec 94 23:57 CST
Date: Tue, 20 Dec 94 23:39:45 CST
Message-Id: <2381@k5yfw.ampr.org>
From: k5yfw@k5yfw.ampr.org (Walter D. DuBose - K5YFW)
Reply-To: k5yfw@sat.n5lyt.ampr.org
To: hfsig@tapr.org
Subject: Re: [HFSIG:146] Re: HF Modulation Modes
In-Reply-To: Your message of Tue, 20 Dec 94 18:27 CST
X-Mailer: Bdale's Mailer version PA3AZK.940404 (MSDOS)

In message <B5855F80B9A@frl.orst.edu> you write:
        [stuff deleted]
> I have some further specifications on its BER, but unfortunately not
> with me at the moment. Walt, K5YFW, could perhaps attest how these
> have been doing on the military HF nets. This is living proof that
> phase modulation is worth considering on HF.
        [stuff deleted]
> 73's
> 
> Johan, KC7WW


Do you "guys" remember all those "Sadamn" cartoons during Desert
Shield/Storm?  Well, bunches of them originated in Saudi.  We would hook
the RS-232 (I/O) of a FAX machine to a Harris MIL-STD-188-110c modem run
the 39 tone mode and FAX them out to the troops at 2400 BPS using only
100 watts (AN/URC-119 HF system by Harris).  Data input was thru the
aux. audio jack (a DB-9) and running USB.  We would pass a page in just
a couple of minutes.

Ok, so how did the Patriot missile know where to "point" in the sky to
lock onto a Skud?  Easy, the AWACS caught the ground launch, snapped a
video picture from the radar and sent the picture, with Lat/Long data,
via HF radio and a MIL-STD-188-110c modem down the the Harris HF radio
and MIL-STD modem in the Patriot missile battery and the battery pre-
positioned its radar antennas and missile tubes in the correct part of
the sky to intercept the Skud.  And all this time you thought the
Patriot missile was doing it all.  Yep AWACS to Patriot in less than a
minute.  Did I mention digital encrypted voice on HF?  Guess I'd better
not on that one.

Hello from Levenworth.

73,

Anonymous
From BobH@eworld.com Wed Dec 21 06:23:25 1994
Return-Path: <BobH@eworld.com>
Received: from hp1.online.apple.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rKQ4g-0000fLC; Wed, 21 Dec 94 06:23 CST
Received: by hp1.online.apple.com
	(1.38.193.5/16.2) id AA15759; Wed, 21 Dec 1994 04:23:20 -0800
From: BobH@eworld.com
X-Mailer: AOS Mailer
Sender: "BobH" <BobH@eworld.com>
Message-Id: <9412210423.tn19172@eworld.com>
To: hfsig@tapr.org
Date: Wed, 21 Dec 94 04:23:15 PST
Subject: Achieving regulation by bandwidth

I'm glad someone mentioned the appropriateness of a modulation technique for
"noisy, interference-prone" channels. Narrow-band co-channel interference
(QRM) is getting my attention as the missing sun spots force more hf users
into competition on lower and lower and fewer and fewer frequencies.

Analyze your modulation scheme's BER in white noise and then analyze it again
this time with a +30dB 850 shift 75 baud binary FSK signal in the middle of
it.

The commercial single tone modems waveshape spread to 3 khz and then use
adaptive narrow band interference suppressers to notch out several jammers on
the channel. The only energy to "shine" on the detector is the wanted signal.

QRM is a good argument for relaxing the bandwidth limits for new digital
modes ( in what at first seems to be a paradox  but really isn't as others on
this SIG and elsewhere have pointed out). We can co-exist with current
user's: We notch them out; they power through us. Or our signal processing
gain spreads them and de-spreads us, something like that.

If we don't have the MIPS and the algorithms for  the STANAG and the MIL-STD
adaptively equalized single tone hf modems, I saw an alternative:
"A chirp modem incorporating interference excision" IEE Proceedings Vol. 139,
Aug 1992 .
They chirp from 300-3000 Hz using a TMS320C25 and "recent work has increased
the data rate to 600 bits/s". Looks easy,  fun, robust and illegal!

Bob





From FORRERJ@frl.orst.edu Wed Dec 21 11:05:29 1994
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rKURM-0000V1C; Wed, 21 Dec 94 11:03 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id BAA00187 for <hfsig@tapr.org>; Wed, 21 Dec 1994 01:24:44 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Wed, 21 Dec 94 8:44:01 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 21 Dec 94 8:43:38 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Wed, 21 Dec 1994 08:43:35 PST8PDT
Subject:       Re: [HFSIG:149] Re: HF Modulation Modes
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <B68A31F1F55@frl.orst.edu>

Alan Bloom, N1AL wrote:

>On the receiving end, I presume you would just run a DFT on the
>incoming sampled data which would output the frequency and phase
>of each carrier.  It is effectively coherent detection, since
>the phase is known.


That is good news Alan. After your post, I spent last night digging out
all the stuff that I had on the MIL-STD-188 39-tone parallel modems, and
what a surprize - now that I know a little better what to look for.

The 39-tone system is, by definition, what you called ODFM. It comprizes
39 tones, spaced to obtain orthogonal signaling, with each tone TDPSK
(4 phase) modulated (I don't quite understand yet what this means? Anyone 
pse). Although very few manufacturers actually tell you how they do 
their demodulation, I found one reference to it: 128 point FFT! All these 
systems occupy a typical voice bandwidth channel and even when it operates 
at lower bit rates, never uses less bandwidth, but uses redundancy instead. 
The figures for BER for these 39-tone modems, as specified minimum 
performance specs (from MIL-STD-188-110 document), requires:
1.8e^-4 at 30 dB S/N for 2400 bps, 2.7e^-6 also at 30 dB S/N for 1200 bps. 
At 75 bps 1.0e^-6 for 8 dB S/N. I think wwill agree that this is not 
bad. Keep in mind that all these BER merits relies heavily on coding, 
i.e. block or convolutional combined with interleaving. All the specs that 
I looked at also includes some form of tracking for doppler, i.e. +/- 75Hz, 
at a rate of 3.5 Hz/second. One small tidbit was that one manufacturer 
actually disclosed that an M68030 was used as a controller in conjunction 
with two M56002's. 

Does anyone have further references to such ODFM modulation schemes?
I would be very interested to hear more.

Thanks for all the excellent contributions - we are making good 
progress.

73's

Johan, KC7WW


From larry@owrlakh.unbc.edu Wed Dec 21 11:15:44 1994
Return-Path: <larry@owrlakh.unbc.edu>
Received: from owrlakh.unbc.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rKUdU-0000kAC; Wed, 21 Dec 94 11:15 CST
Received: (from larry@localhost) by owrlakh.unbc.edu (8.6.9/8.6.9) id JAA08836 for hfsig@tapr.org; Wed, 21 Dec 1994 09:15:20 -0800
From: Larry Gadallah <larry@owrlakh.unbc.edu>
Message-Id: <199412211715.JAA08836@owrlakh.unbc.edu>
Subject: Re: HF Modulation Modes
To: hfsig@tapr.org
Date: Wed, 21 Dec 1994 09:15:19 -0800 (PST)
In-Reply-To: <9412202217.AA06592@eagle.sr.hp.com> from "Alan Bloom" at Dec 20, 94 04:18:00 pm
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1781      

> 
> In all the discussion about the best modulation format for HF, I'm
> surprised nobody has mentioned OFDM.  Orthogonal frequency-division
> multiplex is proposed for Digital Audio Broadcasting and digital TV
> in Europe, although it is not so well known in the US.
> 
> The idea is to split the signal up into a large number (like 128 or
> 1024) equally-spaced carriers, each modulated at the same symbol rate.  
> I believe the DAB standard proposes that each carrier be modulated 
> with QPSK, but you can use any modulation in which each symbol can be 
> represented by a phase and amplitude.  That includes the many forms of 
> QAM, PSK, PI/4 DQPSK, on-off keying, whatever.
> 

Isn't this what Telebit does for its Packetized Ensemble Protocol (PEP)
used for long haul high-speed landline modem connections? Some of my
colleagues and I have occasionally wondered about using a couple of
Telebits for HF modems, despite the obvious legal problems.

I have also considered the idea that OFDM is a coarse grained form of
spread spectrum, albeit with little spreading. Wouldn't it be nice
to be able to spread a 1 kbps signal over a 3 khz bandwidth and thus
provide some protection against interference and fades? How about
feeding a 1 kbps data stream into a DSP and producing a 300 to 3300
Hz DS spread spectrum signal that could be piped directly into the
modulator of an HF rig. I guess there could be problems with modulator
non-linearity.

73,
-- 
---------------------------------------------------------------------
Larry Gadallah VE4TCP/VE6VQ          Prince George, BC
Internet: larry@owrlakh.unbc.edu     TPC: (604) 964-1140
                                     ICBM: 53:51'38.4"N 122:44'25.8"W
---------------------------------------------------------------------
From rs@ife.ee.ethz.ch Wed Dec 21 13:18:55 1994
Return-Path: <rs@ife.ee.ethz.ch>
Received: from bernina.ethz.ch by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rKWWr-00018FC; Wed, 21 Dec 94 13:16 CST
Received: from ife (actually ife-gw.ethz.ch) by bernina.ethz.ch 
          with SMTP inbound; Wed, 21 Dec 1994 20:15:25 +0100
From: Rolf Sommerhalder <rs@ife.ee.ethz.ch>
Message-Id: <9412211915.AA21592@ife>
Received: from ife.ee.ethz.ch (gillespie) by ife.ee.ethz.ch id AA21592;
          Wed, 21 Dec 1994 20:15:24 +0100
Received: by gillespie.ethz.ch; Wed, 21 Dec 94 20:15:23 +0100
Subject: Re: [HFSIG:153] Re: HF Modulation Modes
To: hfsig@tapr.org
Date: Wed, 21 Dec 94 20:15:23 MET
In-Reply-To: <B68A31F1F55@frl.orst.edu>; from "Johan Forrer FL" at Dec 21, 94 11:10 am
content-length: 1082

> ... One small tidbit was that one manufacturer 
> actually disclosed that an M68030 was used as a controller in conjunction 
> with two M56002's. 

Recently, I had the chance to have a view into a pair of pre-production MIL-STD-188
parallel- (and serial-) tone HF-modems (the kind of olive-green painted brand and price-tag).
The job is done by two ADSP-2100 16-bit fixed point DSPs from Analog Devices.
This job can probably done soon by a single DSP like a 80 or 100 MHz TMS320C50 or similar.

73s,
Rolf

-- 
                                --- * * * ---

Rolf Sommerhalder                             
Swiss Federal Institute of Technology (ETH)   home address:
Electronics Laboratory ETZ H60.1              c/o Rindlisbacher
Gloriastrasse 35                              Wermatswilerstrasse 96
8092 Zurich / Switzerland                     8610 Uster / Switzerland

Voice +41 1 632 76 40 (or 632 51 53)          Voice +41 1 941 59 28
Fax   +41 1 632 12 10                         AX.25 HB9CWP @ HB9OS
E-Mail rolf.sommerhalder@ife.ee.ethz.ch       Swiss Disaster Relief HBK81

From BLOOM_ALAN/HP5300_R0@opnmail3.corp.hp.com Wed Dec 21 13:48:46 1994
Return-Path: <BLOOM_ALAN/HP5300_R0@opnmail3.corp.hp.com>
Received: from hp.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rKX1c-0001AlC; Wed, 21 Dec 94 13:48 CST
Received: from opnmail3.corp.hp.com by hp.com with SMTP
	(1.37.109.14/15.5+ECS 3.3) id AA197729310; Wed, 21 Dec 1994 11:48:30 -0800
Received: from  by opnmail3.corp.hp.com with SMTP
	(1.37.109.8/15.5+ECS 3.3) id AA11034; Wed, 21 Dec 1994 11:48:29 -0800
From: BLOOM_ALAN/HP5300_R0@opnmail3.corp.hp.com
X-Openmail-Hops: 2
Date: Wed, 21 Dec 94 11:48:00 -0800
Message-Id: <d0eqY8Z000000000@MHS>
Subject: Re: HF Modulation Modes
To: hfsig@tapr.org

Walt@home.2.nite said:

>Gee Alan, kinda sounds like the 16 and 39 parallel tone modem formats in
>MIS-STD-188-110c.    ...

Kinda.  Although with only 16 or 39 tones, using a FFT/IFFT is not very
efficient, since you don't have 2^N tones.  With fewer tones, you need
a higher symbol rate to get a desired bit rate, which would require
more DSP horsepower.  As Bob said:

BobH said:

>If we don't have the MIPS and the algorithms for the STANAG and the
>MIL-STD adaptively equalized single tone hf modems...

The advantage of OFDM is the computational efficiency due to using the
FFT.  Equalization is easy:  Just adjust the amplitude and phase of
each of the carriers in the frequency domain before doing the IDFT.

Larry Gadallah said:

>I have also considered the idea that OFDM is a coarse grained form of
>spread spectrum, albeit with little spreading.  ...

It's not really spread, since the total bandwidth is about the same
as a single carrier modulated with the same bit rate.

By the way, on the subject of bandwidth, there is no need for
pre-modulation filtering of the transmitted signal (other than the
standard DAC anti-aliasing filter).  That's because each carrier has
such a low baud rate that even with unfiltered square waveforms
the sinx/x frequency rolloff is fast enough to give an almost-square
frequency spectrum for the composite signal.

Alan
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Subject: Re: [HFSIG:141] Re: Achieving regulation by bandwidth
Reply-To: karn@qualcomm.com

Johan,

This stuff is well covered in communications theory textbooks, but here's
a shot.

Entropy is a measure of information content. It's also a measure of
uncertainty.  Receiving a bit that you always know will be a "1" or a
"0" carries no real information; its entropy is 0 bits. A bit that is
(to you) completely unpredictable and has a 50-50 chance of being
either a 1 or a 0 carries 1 bit of entropy. A bit that is skewed, i.e.,
has some uncertainty to it but can be predicted with better than chance
odds has entropy somewhere between 0 and 1 bit.

Compression algorithms increase entropy in a data stream by removing
redundancy. An ideal compression algorithm produces output with 1 bit
of entropy per compressed data bit.

Channel capacity on an additive white gaussian noise channel is
defined by Shannon's famous formula

		C = B log2(1 + S/N)

where	C = channel capacity in bits/sec ("real" bits, with 1 bit entropy each)
	B = channel bandwidth in Hz
	S = received signal power in watts
	N = received noise power in watts

The important thing to note about the Shannon equation is the
fundamental tradeoff between bandwidth and S/N. The wider the
bandwidth, the lower the S/N required to maintain a constant
capacity. And the narrow the bandwidth, the higher the S/N required.

Since N also depends on bandwidth it's usually more instructive to
consider Eb/N0 instead of S/N:

	Eb/N0 = (S/R) / (N/B) = S/N * B/R

where	Eb = received energy per bit in joules
	N0 = received noise spectral density in watts/Hz.
	R = data rate in bits/sec

Note that Eb/N0 is independent of signal bandwidth. Eb/N0 is still
dimensionless (just like S/N) since watts/Hz also has units of
joules. It is equal to S/N only for the case where the modulation
bandwidth in Hz equals the data rate in bits/sec. Eb/N0 is now
universally used in describing the performance of a modem against
white noise.

If you substitute this into Shannon's formula and solve for Eb/N0 you
get

	Eb/N0 = B/R * (2^(R/B) - 1)

This tells you the absolute minimum Eb/N0 that any modem must have
when operating at a specified data rate R and bandwidth B. Real modems
will of course require more. In the limit of B/R = infinity, i.e.,
infinite bandwidth for a finite data rate, Eb/N0 = -1.6 dB, the famous
Shannon limit.  Note, though, that this applies ONLY to infinite
bandwidth.  For finite values of R/B, the required Eb/N0 is
higher. E.g., for R/B of unity, the minimum Eb/N0 is 0 dB.  For an R/B
of about 4 bit/sec/Hz, the minimum Eb/N0 is about +6 dB. If you make
R/B less than 1, eg, by adding FEC, the minimum required Eb/N0 drops
below 0 dB.  For a rate 1/2 code, this is about -.8 dB. Real,
implementable codes at this rate can get down to about +2.5 dB; I've
done this with soft decision sequential decoding.

Note that a "bit" represented by Eb is a real user data bit, NOT a
coded channel symbol. That's another reason to use Eb/N0: it takes FEC
into account. FEC provides a real power gain in that I can use fewer
transmitter watts to send a given number of user data bits per second.
But there's no free lunch; my transmitter power savings come at the
expense of additional bandwidth. FEC simply allows me to play with the
terms in the Shannon equation and to come more closely to its limits;
it doesn't allow me to violate it.

Power efficiency has traditionally been considered important only in
situations like deep space communications where transmitter power is
an absolute premium. But it's now getting quite a bit of attention
even where RF power is relatively cheap: the shared terrestrial
channel. That's because a modulation method that requires relatively
low Eb/N0 is not only more tolerant of interference (considering
interference to be part of the noise) but it also generates less
interference to others since it needs less power to communicate.

This is a win-win approach much like reducing weight in a car: the
lighter you make the car frame, the lighter the engine you need to
move it, which means an even lighter frame to carry the weight of the
engine, which means an even lighter engine, and so on.

It turns out that at least in cellular mobile communications, the
savings from reduced interference and increased interference tolerance
more than make up for the extra bandwidth required. This is the basis
of the CDMA spread spectrum stuff we've been developing at Qualcomm.

I'm convinced that same principles apply to *any* shared, interference
limited RF environment, including HF. John Costas said as much when he
wrote his famous paper, "Poisson, Shannon and the Radio Amateur" that
appeared in the Proceedings of the IRE, December 1959. (It has been
reprinted in many places, such as the IEEE book "Multiple Access
Communications", edited by Norman Abramson, ISBN 0-87942-292-0.)

Phil
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Date: Thu, 22 Dec 1994 01:59:58 -0800
From: Phil Karn <karn@unix.ka9q.ampr.org>
Message-Id: <199412220959.BAA05620@unix.ka9q.ampr.org>
To: FORRERJ@frl.orst.edu
CC: hfsig@tapr.org
In-reply-to: <B570F42212D@frl.orst.edu> (FORRERJ@frl.orst.edu)
Subject: Re: [HFSIG:145] Re: HF Modulation Modes
Reply-To: karn@qualcomm.com

>This is interesting - one question: did we overcome the need for
>coherent detection, or does it matter?

>From briefly browsing the MIL specs, it looks like they dedicate one
of the carriers to serve as an unmodulated phase and frequency
reference for the others.

Qualcomm CDMA does something similar on the forward (base->mobile)
link.  There's a spread but otherwise unmodulated component called the
pilot that is always present.  It's several dB stronger than the
traffic channels. The mobiles use it as a timing, phasing and
frequency reference for everything else they do. This works well in
our system because a single pilot can be shared by all of the channels
in the system. The reverse link has no pilot, so we use a form of
64-ary orthogonal modulation instead to make up most of the loss from
noncoherent demodulation.

Phil
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Date: Thu, 22 Dec 1994 02:18:15 -0800
From: Phil Karn <karn@unix.ka9q.ampr.org>
Message-Id: <199412221018.CAA05738@unix.ka9q.ampr.org>
To: BLOOM_ALAN/HP5300_R0@opnmail3.corp.hp.com
CC: hfsig@tapr.org
Reply-To: karn@qualcomm.com
In-reply-to: <"d0eqoS-000000000*"@MHS> (BLOOM_ALAN/HP5300_R0@opnmail3.corp.hp.com)
Subject: Re: [HFSIG:149] Re: HF Modulation Modes

>On the receiving end, I presume you would just run a DFT on the
>incoming sampled data which would output the frequency and phase
>of each carrier.  It is effectively coherent detection, since
>the phase is known.

Not necessarily. Just because you can measure the received phase
doesn't imply you know what phase was sent. But if you dedicated one
of the channels to be an unmodulated phase reference, then you could
probably use this to determine the transmitted phase in the other
channels, assuming that the channel isn't too dispersive.

Phil
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Date: Thu, 22 Dec 1994 02:49:23 -0800
From: Phil Karn <karn@unix.ka9q.ampr.org>
Message-Id: <199412221049.CAA05769@unix.ka9q.ampr.org>
To: k5yfw@k5yfw.ampr.org
CC: hfsig@tapr.org
Reply-To: karn@qualcomm.com
In-reply-to: <2381@k5yfw.ampr.org>
Subject: Re: [HFSIG:151] Re: HF Modulation Modes

Hmm, MIL-STD-188-110C...is that anything like MIL-STD-188-110A? I just
ran off a bunch of copies of the latter for the people who requested
them, and now I wonder if I didn't have the latest revision. The date
on the -110A version is 30 September 1991, which superseded -110 dated
15 November 1980.

If -110A didn't become active until late 1991, after the Gulf War was
over, then how could you have used -110C modems?  From looking at the
standard it sure does *seem* like the same thing; there's a 16 tone
mode and a 39 tone mode.

By the way, for anyone interested in actually implementing this spec,
I note that it specifies a rate 1/2 K=7 convolutional FEC.  Several
months ago I wrote and debugged a fast soft-decision Viterbi decoder
for this particular code as it's a widely used standard (e.g., the
Voyager spacecraft).

After considerable cycle bumming my decoder runs at 41 kb/s on a 66
Mhz 486 (32-bit protected mode, GCC 2.5.8 with full optimization).
Should be plenty fast for this application. I'd be happy to make it
available.

Phil
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Date: Thu, 22 Dec 1994 03:15:12 -0800
From: Phil Karn <karn@unix.ka9q.ampr.org>
Message-Id: <199412221115.DAA05783@unix.ka9q.ampr.org>
To: k5yfw@k5yfw.ampr.org
CC: hfsig@tapr.org
In-reply-to: <2381@k5yfw.ampr.org>
Subject: Re: [HFSIG:151] Re: HF Modulation Modes

>Ok, so how did the Patriot missile know where to "point" in the sky to
>lock onto a Skud?  Easy, the AWACS caught the ground launch, snapped a
>video picture from the radar and sent the picture, with Lat/Long data,
>via HF radio and a MIL-STD-188-110c modem down the the Harris HF radio
>and MIL-STD modem in the Patriot missile battery and the battery pre-

Hmm, considering that the more sober studies made after the war
concluded that there was no hard evidence that even ONE SCUD missile
had been successfully engaged and destroyed, perhaps we should
consider a different HF modem technology?

:-)

More seriously, I did get a chance to leaf through the Ralphs book
this afternoon in the UCSD library. I hadn't renewed my library card,
so I had to get the gist of it in the 45 min remaining before the
library closed. (Bad planning, I know). I also noted the comparisons
between the Piccolo-style MFSK modems used by the British foreign service
and the multicarrier PSK systems that seem to be favored by the US
military. The Eb/N0 curves were significantly better for Piccolo. The
discussion commented that the multicarrier PSK systems did require much
better channel conditions.

This matches my understanding of the problem. Now it is true that real
HF channels are not always as bad as the pure Rayleigh model would
suggest. The fading process is usually bandlimited, limiting the fade
rate, and there are usually only a small number (often 2) of multipath
components. In this situation you *can* get away with phase
modulation.

But if you really want to get the most out of a really lousy channel
with the least power, I think the author is right - MFSK with
noncoherent detection is the way to go. Another part of the book
described some interference tests they did.  One involved running
Piccolo signals "underneath" BBC program material.  The Piccolo signal
could still be copied even when it was so weak as to be only a
slightly noticeable background behind the audio program.

Phil
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Sender: "BobH" <BobH@eworld.com>
Message-Id: <9412220417.tn32612@eworld.com>
To: hfsig@tapr.org
Date: Thu, 22 Dec 94 04:17:50 PST
Subject: HF Modulation Modes

I just got my "QEX" for December: 
STANAG 4285 kicks butt!

Which leads to one question (of many)
to which I'm sure no simple answer 
exists:

Which code is "better" for the hf channel:
> A convolutional code with interleaver.
                           or
> A R-S block code with soft decision.

????
Or is that even the right question?

If we only had a channel simulator.


bob wm6h
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Date:          Thu, 22 Dec 1994 09:03:49 PST8PDT
Subject:       Re: [HFSIG:101] Ideas for HF modulation and coding
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <B80FA331EF6@frl.orst.edu>

Phil,

Thanks much for the brief note on Shannon - it always is a 
good reality check to keep those principles in mind.

OK - I am ready to start playing with some of these great ideas - perhaps
we can start looking into some of the practical details now. 
It would not be difficult to simulate the multi-tone signals in a
C program, and then play with the different ideas on demodulation. 

It appears there are two ideas put forward:

1) (ODFM) n-parallel carriers with orthoganal signaling. All carriers 
are always present. Demodulation is performed by FFT's. It is obvious that
the choice of the FFT size and sample rate have to just right otherwise we 
will end up with an odd distribution of our carriers over the 
frequency/phase bins. After this choice have been made, how do I use this 
I/Q recovered data? I have some wild ideas, but would like to obtain 
further input first.

2) (Phil's method based on Welch functions) n-parallel tones with orthoganal 
signaling. Only a small subset of carriers are present at a time - the
different subset is selected from a Hamadard matrix. In a sense, 
Piccolo may be considered a special case of this idea, where only one 
carrier is sent at a time from a set of m-carriers. Phil mentioned that FHT 
(is that for fast hadamard transform?) is used to perform demodulation. How 
about telling us a bit more about how to implement this one Phil.


73's

Johan, KC7WW
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Date: Thu, 22 Dec 94 11:01:21 -0600
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW)
Subject: Which Modem
To: hfsig@tapr.org
Cc: tbruns@datarace.com

The question has been ask "which modem?"

I think the answer is, we don't know at this point in time.

While members of this group are gathering information about different
modems and techniques, they are also gathering information about a how
to create an HF channel simulator.  Once a simulator is developed, we
can evaluate different modems and techniques.  The group can then
begin to evaluate different modems and modem techniques.

I wish we were already to release code for a soundcard that would make
2400 BPS possible on HF.  But, most/all of us have to put beans on the
table for ourselves and/or family.  I keep telling myself this *is* a
hobby.

When it comes time to release code for on-the-air testing, and
before, we are going to need an informed member base to carry our
torch to the rest of the ham world...this isn't going to be easy and
we will have a great amount of resistance.  But, we must be ready,
informed and ready to fight.

One thing to keep in mind is that *when* we are successful, we will
be giving the ham radio world a wonderful new "toy" and make robust,
high speed data transmissions on HF available at an affordable price
to the entire world.

73 & Happy Holidays,

Walt/K5YFW
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Date: Thu, 22 Dec 94 11:38:03 -0600
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW)
Subject: Re: [HFSIG:161] Re: HF Modulation Modes
To: hfsig@tapr.org
Cc: tbruns@datarace.com
X-orig-date: Thu, 22 Dec 94 05:20 CST
X-orig-from: Phil Karn <karn@unix.ka9q.ampr.org>
X-orig-message-ID: <199412221115.DAA05783@unix.ka9q.ampr.org>

In your message of 22 Dec 1994 at 0520 CST, you write:
> >Ok, so how did the Patriot missile know where to "point" in the sky to
> >lock onto a SCUD?  Easy, the AWACS caught the ground launch,
snapped a
> >video picture from the radar and sent the picture, with Lat/Long data,
> >via HF radio and a MIL-STD-188-110c modem down the the Harris HF radio
> >and MIL-STD modem in the Patriot missile battery and the battery pre-
>
> Hmm, considering that the more sober studies made after the war
> concluded that there was no hard evidence that even ONE SCUD missile
> had been successfully engaged and destroyed, perhaps we should
> consider a different HF modem technology?
>
> :-)

        The video taken by my troops from atop of the villas in Eskan
        Village just outside of the Saudi Capital (50,000 + U.S.
        troops lived in Eskan Village) indicated that there were
        direct hits.  Whether they destroyed, deflected or made a
        difference in the targeting is an opinion.

        The data provided by the HF to the Patriot sites only helped
        the site point their radar antennas in the right part of the
        sky, it had nothing to do with the radar acquisition/lockon
        of the SCUD or the capability of the missile system destroying
        the target.  A Patriot Missile Battery cannot "look" at the
        entire "sky" in front of it, just one quadrant.


>
> More seriously, I did get a chance to leaf through the Ralphs book
> this afternoon in the UCSD library. I hadn't renewed my library card,
> so I had to get the gist of it in the 45 min remaining before the
> library closed. (Bad planning, I know). I also noted the comparisons
> between the Piccolo-style MFSK modems used by the British foreign service
> and the multicarrier PSK systems that seem to be favored by the US
> military. The Eb/N0 curves were significantly better for Piccolo. The
> discussion commented that the multicarrier PSK systems did require much
> better channel conditions.
>
> This matches my understanding of the problem. Now it is true that real
> HF channels are not always as bad as the pure Rayleigh model would
> suggest. The fading process is usually bandlimited, limiting the fade
> rate, and there are usually only a small number (often 2) of multipath
> components. In this situation you *can* get away with phase
> modulation.
>
> But if you really want to get the most out of a really lousy channel
> with the least power, I think the author is right - MFSK with
> noncoherent detection is the way to go. Another part of the book
> described some interference tests they did.  One involved running
> Piccolo signals "underneath" BBC program material.  The Piccolo signal
> could still be copied even when it was so weak as to be only a
> slightly noticeable background behind the audio program.
>

        Do we want to design a modem for the worse-case scenario or
        can we live with one that can get data thru on the worst
        channel part of the time.  I have a pick-up without 4 wheel
        drive...there are at times places I can't drive...so I don't
        drive there until conditions are better.  There are places
        where I can drive without 4 wheel drive that my Geo Metro can
        never go.  Should I have 4 wheel drive?  Do we need a modem
        that can get thru even the worst conditions or can we settle
        for something less.  Are we purist or realists?

Walt (dba k5yfw)
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Date: Thu, 22 Dec 94 12:17:44 -0600
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW)
Subject: Re: [HFSIG:160] Re: HF Modulation Modes
To: hfsig@tapr.org
X-orig-date: Thu, 22 Dec 94 04:56 CST
X-orig-from: Phil Karn <karn@unix.ka9q.ampr.org>
X-orig-message-ID: <199412221049.CAA05769@unix.ka9q.ampr.org>

Phil,

In your message of 22 Dec 1994 at 0456 CST, you write:
> Hmm, MIL-STD-188-110C...is that anything like MIL-STD-188-110A? I just
> ran off a bunch of copies of the latter for the people who requested
> them, and now I wonder if I didn't have the latest revision. The date
> on the -110A version is 30 September 1991, which superseded -110 dated
> 15 November 1980.
>
> If -110A didn't become active until late 1991, after the Gulf War was
> over, then how could you have used -110C modems?  From looking at the
> Standard it sure does *seem* like the same thing; there's a 16 tone
> mode and a 39 tone mode.

Make that 110Xb, The appendix(?) for HF modems in the copy I have
shows "b" for the 39 tone modem and "c" for the serial tone Harris
modem.  I don't have the complete MIL-STD, just the part on the
modems...and that was given to me by the Harris RF Comm. 1Div.

I'm glad someone is keeping me straight and honest, my XYL, WB5WXY,
has failed at that task for the last 30 years.

Walt
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Date: Thu, 22 Dec 94 12:46:27 -0600
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW)
Subject: Frederick Electronics Modem
To: hfsig@tapr.org
Cc: tbruns@datarace.com

High Performance Data Modem

SFA DataComm, Inc.
    Frederick Electronics
7450 New Technology Way,
P.O. Box 502
Frederick, MD  21701
(301) 662-5901


Model 1102      NSN 5895-66-136-4191   ($7,500 U.S.)

Capable of Tx and RX up to 2400 BPS in a standard 3 KHz ssb HF radio
channel...meets Mil. Standard 188-110A

3.47"H x 17"W x 16"D (19" Rack mounting) Approx. 12 lbs

....Convolutional coding with soft decision Viterbi decoding....

....Interleaving...

...User friendly interface...movement between windows...

Additional planned capabilities:

16 tone DPSK per MIL-STD-188-110a
39 tone DPSK per MIL-STD-188-110a
NATO mode IAW STANAG 4285  (3600 BPS)
16 channel VFT mode (R.39)
From k5yfw  Thu Dec 22 14:17:25 1994
Return-Path: <k5yfw@sacdm10.kelly.af.mil>
Received: from sacdm10.kelly.af.mil by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rKtww-00011sC; Thu, 22 Dec 94 14:17 CST
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2)
	id m0rKttM-0002AmC; Thu, 22 Dec 94 14:13 CST
Resent-Message-Id: <m0rKttM-0002AmC@sacdm10.kelly.af.mil>
Resent-date: Thu, 22 Dec 94 14:13:40 -0600
Resent-from: k5yfw (WALT DUBOSE - K5YFW)
Subject: Fw: Oops, I lied Again
Resent-to: hfsig@tapr.org
Date: Thu, 22 Dec 94 12:28:47 -0600
From: k5yfw (WALT DUBOSE - K5YFW)
Subject: Oops, I lied Again
To: hfsig

Oops, I lied again.  The copy of the part MIL-STD-188-110 that I
have says:

MIL-STD-188-110
NOTICE 2
4 November 1988

APPENDIX B, 16-TONE DIFFERENTIAL PHASE-SHIFT KEYING (DPSK) MODE
APPENDIX C, 39-TONE MODE

Walt
From jmorriso@bogomips.ee.ubc.ca  Fri Dec 23 12:51:37 1994
Return-Path: <jmorriso@bogomips.ee.ubc.ca>
Received: from bogomips.ee.ubc.ca by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rLEzS-0000hSC; Fri, 23 Dec 94 12:45 CST
Received: by bogomips.ee.ubc.ca (Linux Smail3.1.29.1 #3)
	id m0rLExU-0004giC; Fri, 23 Dec 94 10:43 PST
Message-Id: <m0rLExU-0004giC@bogomips.ee.ubc.ca>
From: jmorriso@bogomips.ee.ubc.ca (John Paul Morrison)
Subject: Re: [HFSIG:161] Re: HF Modulation Modes
To: hfsig@tapr.org
Date: Fri, 23 Dec 1994 10:43:19 -0800 (PST)
In-Reply-To: <199412221115.DAA05783@unix.ka9q.ampr.org> from "Phil Karn" at Dec 22, 94 05:20:00 am
X-Linux: watch for Linux '94 aka "Helsinki"
X-Bogomips: 33.55
X-Mailer: ELM [version 2.4 PL22]
Content-Type: text
Content-Length: 1153      

> But if you really want to get the most out of a really lousy channel
> with the least power, I think the author is right - MFSK with
> noncoherent detection is the way to go. Another part of the book
> described some interference tests they did.  One involved running
> Piccolo signals "underneath" BBC program material.  The Piccolo signal
> could still be copied even when it was so weak as to be only a
> slightly noticeable background behind the audio program.


This isn't related to HF, but: would some modulation like Piccolo (I
think I missed the description for that) be applicable to sending a
data stream over a 2m or 70cm narrow-band FM voice radio? And
preferably through a voice repeater as well. Speed would be  about 50
bps or so, just enough to send your callsign or a very short message
when you key up the radio.

> 
> Phil
> 

---------------------------------------------------------------------------
BogoMIPS Research Labs  --  bogosity research & simulation  --  VE7JPM  -- 
jmorriso@bogomips.ee.ubc.ca ve7jpm@ve7jpm.ampr.org jmorriso@ve7ubc.ampr.org
---------------------------------------------------------------------------
From 70730.3472@compuserve.com Mon Dec 26 18:57:05 1994
Return-Path: <70730.3472@compuserve.com>
Received: from arl-img-1.compuserve.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rMPlX-0001j8C; Mon, 26 Dec 94 18:27 CST
Received: by arl-img-1.compuserve.com (8.6.9/5.940406sam)
	id SAA12850; Mon, 26 Dec 1994 18:26:33 -0500
Date: 26 Dec 94 18:25:39 EST
From: Johan Forrer <70730.3472@compuserve.com>
To: HFSIG <HFSIG@tapr.org>
Subject: HF modulation
Message-ID: <941226232538_70730.3472_CHK57-1@CompuServe.COM>

Hi,

As a way to learn more about how OFDM works for the
39-tone MIL-STD-188 parallel modem, I wrote a C program that simulates 
39 parallel tones and combines them into a single output signal. The
program then continues by modulating (DQPSK) each of these tones, using 
a simple binary pattern, i.e., 00 -> 01 -> 10 -> 11 (remember these
are di-bits). This gives an effective raw rate of 2*39*56.25 = 4387.5 bps (56.25
baud for each of the 39 channels) using a 3 kHz voice channel. Although I have
not explored further aspects as yet, several	transmission speeds ranging form
75 - 2400 bps are possible by using some of the channels for redundancy.
Error-correction coding is 
futher included that trades off between these bit rate and robustness.

The program then continues the demodulation process by capturing 128 
data points and performing an FFT. This produces 64 positive frequencies
of which only 39 are used - the remainder are disregarded or treated as 
guard bands - as would be required when such a system are to be used with 
a voice-grade IF filter. Shown in Table 1, below, are the recovered I and Q data

for four channels, i.e., the first four channels of 39. It is evident that, with
proper bit synchronization (which is fairly well documented for the MIL-STD
modems), things seem to work out remarkably well.

I also did capture the simulated output waveform and was quite concerned
after inspecting the plot  -  the presence of large spikes of significant
magnitude (in some cases, some 10-15 dB over the RMS value). This
situation will certainly introduce data errors if not addressed. It should be
stressed
that such a signal will sound like a noise burst - it has little or no melody
associated with
it, except for the bit synchronizing pre-ambles. 

It ir my opinion, that after this initial analysis, that such a scheme may be
quite doable on our present hardware. I have no doubt that, if signal synthesis
and fast
Fourier transform are performed on the DSP side,  there should be plenty of
computing power in a modest PC to run the remainder of such a modem, even
considering the computing demands for error coding. 

Hope you all enjoyed the holiday season. Trust that 1995 will hold
the best in health peace for you. 

73's

Johan, KC7WW



Table 1. 

An evaluation of the MIL-STD-188 modem using OFDM.

  -----------------------------------------------------------------------
 BAUD #  I  Q		Freq    Real   Imag   <- appears swapped 
  -----------------------------------------------------------------------
       1       0  0		675.00  45.25 -45.25 
       2       0  1		675.00 -45.26  45.24   
       3       1  0		675.00  45.28 -45.23   
       4       1  1		675.00 -45.31  45.20   
  -----------------------------------------------------------------------
       1       0  1		731.25 -45.25  45.25   
       2       1  0		731.25  45.26 -45.24   
       3       1  1		731.25 -45.22 -45.27   
       4       0  0		731.25  45.23  45.24   
  -----------------------------------------------------------------------
       1       1  0		787.50  45.25 -45.25   
       2       1  1		787.50 -45.24 -45.26   
       3       0  0		787.50  45.24  45.28   
       4       0  1		787.50 -45.30  45.22   
  -----------------------------------------------------------------------
       1       1  1		843.75 -45.25 -45.25   
       2       0  0		843.75  45.24  45.26   
       3       0  1		843.75 -45.25  45.23   
       4       1  0		843.75  45.20 -45.31 
  -----------------------------------------------------------------------
KC7WW, Dec 26, 1994

From karn@qualcomm.com Mon Dec 26 19:00:03 1994
Return-Path: <karn@qualcomm.com>
Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rMQGf-0000uhC; Mon, 26 Dec 94 19:00 CST
Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id RAA18816; Mon, 26 Dec 1994 17:01:51 -0800
Date: Mon, 26 Dec 1994 17:01:51 -0800
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199412270101.RAA18816@servo.qualcomm.com>
To: hfsig@tapr.org
Subject: copies of MIL-STD-188-110A

As I mentioned a week or so ago, I've run off four paper copies of
MIL-STD-188-110A, dated 30 September 1991.

I've also printed MIL-STD-203-1A, "Interoperability and Performance
Standards for Tactical Digital Information Link (TADIL) A", 8 January 1988,
and MIL-STD-188-203-3, "Subsystem Design and Engineering Stadards for
Tactical Digital Information Link (TADIL) C", 5 October 1983. These two
standards seem to discuss earlier multitone modems, perhaps related to
110A.

All standards are completely unclassified and marked "Approved for Public
Release; distribution is unlimited."

I'm sending a copy to Frode, LA2RL. Any other takers? If I get more than
another 3, I can send the laserprinter originals to Greg and he can
run them off with TAPR resources, right Greg? :-)

Phil

From larry@owrlakh.unbc.edu Tue Dec 27 15:23:51 1994
Return-Path: <larry@owrlakh.unbc.edu>
Received: from owrlakh.unbc.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rMjMv-0000hoC; Tue, 27 Dec 94 15:23 CST
Received: (from larry@localhost) by owrlakh.unbc.edu (8.6.9/8.6.9) id QAA00731; Sun, 25 Dec 1994 16:54:28 -0800
From: Larry Gadallah <larry@owrlakh.unbc.edu>
Message-Id: <199412260054.QAA00731@owrlakh.unbc.edu>
Subject: Re: [HFSIG:160] Re: HF Modulation Modes
To: hfsig@tapr.org
Date: Sun, 25 Dec 1994 16:54:27 -0800 (PST)
Cc: karn@unix.ka9q.ampr.org
In-Reply-To: <199412221049.CAA05769@unix.ka9q.ampr.org> from "Phil Karn" at Dec 22, 94 04:57:00 am
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 914       

> By the way, for anyone interested in actually implementing this spec,
> I note that it specifies a rate 1/2 K=7 convolutional FEC.  Several
> months ago I wrote and debugged a fast soft-decision Viterbi decoder
> for this particular code as it's a widely used standard (e.g., the
> Voyager spacecraft).
> 
> After considerable cycle bumming my decoder runs at 41 kb/s on a 66
> Mhz 486 (32-bit protected mode, GCC 2.5.8 with full optimization).
> Should be plenty fast for this application. I'd be happy to make it
> available.
> 
> Phil

I for one would be interested.

Thanks and 73,
-- 
---------------------------------------------------------------------
Larry Gadallah                       Prince George, BC
Internet: larry@owrlakh.unbc.edu     TPC: (604) 964-1140
VE4TCP/VE6VQ                         ICBM: 53:51'38.4"N 122:44'25.8"W
---------------------------------------------------------------------
